Simplify debug evaluate.

Simplify debug evaluate.

R=peter.rybin@gmail.com
BUG=v8:2585, 173608
Committed: https://code.google.com/p/v8/source/detail?r=14019

[Yang, 2013-03-20 12:56:14]

I changed the fix so much that it's probably easier to create a new CL for
review.

Turns out that no builtin is necessary. We just need to pass the correct context
to CompileEval. I wonder why it was implemented in a so round-about way.

Instead of running the compiled closure, you could also just return it to run it
to run it by yourself. However, you would need the receiver too. I don't see how
that would help with syntax errors. You could just check whether the thrown
error is a SyntaxError or not.

[Peter Rybin, 2013-03-20 22:14:07]

LGTM

I tried the code, tried "arguments", tried "new Error().stack" (both versions
expose our internals). Looks fine.

[Peter Rybin, 2013-03-20 22:16:58]

> Turns out that no builtin is necessary. We just need to pass the correct
context
> to CompileEval. I wonder why it was implemented in a so round-about way.

Maybe it was evolution thing?

> Instead of running the compiled closure, you could also just return it to run
it
> to run it by yourself. However, you would need the receiver too. I don't see
how
> that would help with syntax errors. You could just check whether the thrown
> error is a SyntaxError or not.

I guess receiver can be bound.
And you can check against SyntaxError, but again it's not fully accurate and
works only until you try to evaluate expressions like "eval('}')"

[Yang, 2013-03-21 08:39:53]

On 2013/03/20 22:16:58, Peter Rybin wrote:
> > Turns out that no builtin is necessary. We just need to pass the correct
> context
> > to CompileEval. I wonder why it was implemented in a so round-about way.
> 
> Maybe it was evolution thing?
> 
> > Instead of running the compiled closure, you could also just return it to
run
> it
> > to run it by yourself. However, you would need the receiver too. I don't see
> how
> > that would help with syntax errors. You could just check whether the thrown
> > error is a SyntaxError or not.
> 
> I guess receiver can be bound.
> And you can check against SyntaxError, but again it's not fully accurate and
> works only until you try to evaluate expressions like "eval('}')"

I think our error messages on syntax errors in eval are not the best. Maybe I
should work on those before proceeding with the suggestion.

[Yang, 2013-03-21 08:50:37]

Committed patchset #1 manually as r14019 (presubmit successful).