Open
Bug 691894
Opened 13 years ago
Updated 2 years ago
Implement Environment.prototype.eval, .evalWithBindings
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
NEW
People
(Reporter: jorendorff, Unassigned)
References
Details
No description provided.
Reporter | ||
Comment 1•13 years ago
|
||
This turned out to be something of a pain. - The front end isn't set up to handle compiling against a Call object. Only stack frames. This was pretty easy to fix. - ContextStack::pushExecuteFrame had to be rewired a bit to handle running against a Call object without a StackFrame. This was a bit touchy but I think I got it working. - It's impossible to recover the this-value for an execution context given only the lexical environment. The API is incomplete: the method should probably include a way to specify a this-value. - I am worried about DEFVAR and DEFFUN opcodes being emitted that could extend Call environments that the were previously assumed to be inextensible. I didn't try to fix this. - Deciding when to treat the eval code as strict mode (and thus introduce a new variable environment, like strict direct eval) turned out to be hard to specify nicely. - Need to do some more research to figure out how best to handle "arguments". ES5 says "arguments" is a binding in the call environment, but we don't actually implement it that way--at least, I *think* we never do. And I have vague misgivings about adding another vector into the interpreter. So this has been reclassified as a "future plan" for now. We may actually do it but it needs more thought than I can give it today.
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•