Fix uses of eval() with non-string arguments under nosnap/--use-strict

Fix lazy compilation of eval() under nosnap/--use-strict

When running without a snapshot, the GlobalEval function gets lazy compiled.
By the time we compile it, its name is "eval", which causes the parser to
choke (functions named "eval" aren't allowed in strict mode!).

Instead, we now always skip checking the function name when lazy-parsing,
as the name has already been checked appropriately by the preparser.

Also cleaned up other cases that don't require name checking by introducing
FunctionNameValidity enum and passing appropriate values throughout the
parser and preparser.

This lets us pass an additional 18 test262 tests.

BUG=v8:4198
LOG=n

Committed: https://crrev.com/33a373985be86a52b788f0277a8e61a804c602da
Cr-Commit-Position: refs/heads/master@{#29559}

[adamk, 2015-07-09 00:31:50]

adamk@chromium.org changed reviewers:
+ arv@chromium.org

[arv (Not doing code reviews), 2015-07-09 14:16:55]

LGTM

This makes me wonder if we have more failures when we do --use-strict with
nosnap since it makes all of the builtins strict where we might not actually
expect them to be.

[adamk, 2015-07-09 15:21:25]

Looks like my access of global_eval_fun() sometimes occurs at a time when it's
not yet available, will need to look for another fix.

[adamk, 2015-07-09 17:28:55]

adamk@chromium.org changed reviewers:
+ yangguo@chromium.org

[adamk, 2015-07-09 17:28:55]

Hmm, those failing tests are doing something pretty exotic, in that they create
fresh isolates and then run the compiler. I'm not sure this would ever happen in
real code. +yangguo for his thoughts on what to do with those failures (and
generally for his knowledge of nosnap).

[adamk, 2015-07-09 18:53:42]

Here's a different approach which seems to work, so far: ParseInfo has an
"is_native" bit on it.

[arv (Not doing code reviews), 2015-07-09 19:00:59]

LGTM

https://codereview.chromium.org/1227093005/diff/20001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/1227093005/diff/20001/src/parser.cc#newcode1147
src/parser.cc:1147: name = isolate->factory()->empty_string();
Would it be possible to skip the name check instead of changing name?

[adamk, 2015-07-09 19:09:00]

https://codereview.chromium.org/1227093005/diff/20001/src/parser.cc
File src/parser.cc (right):

https://codereview.chromium.org/1227093005/diff/20001/src/parser.cc#newcode1147
src/parser.cc:1147: name = isolate->factory()->empty_string();
On 2015/07/09 at 19:00:59, arv wrote:
> Would it be possible to skip the name check instead of changing name?

Hmm, I see we already have a bool flag we pass to ParseFunctionLiteral for other
strict reserved words...it might be possible to simply widen the scope of that
override.

[adamk, 2015-07-09 20:54:24]

Totally different approach, PTAL

[arv (Not doing code reviews), 2015-07-09 20:58:10]

LGTM

Very nice

[adamk, 2015-07-09 21:28:46]

The CQ bit was checked by adamk@chromium.org

[commit-bot: I haz the power, 2015-07-09 21:29:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1227093005/80001

[commit-bot: I haz the power, 2015-07-09 21:31:21]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-07-09 21:31:29]

Patchset 5 (id:??) landed as
https://crrev.com/33a373985be86a52b788f0277a8e61a804c602da
Cr-Commit-Position: refs/heads/master@{#29559}