Fix 'eval' in class extends clauses to be always-strict

Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.

BUG=v8:4970
LOG=n

Committed: https://crrev.com/c8a342a5825a835556e0ae26f8a1295b80d02489
Cr-Commit-Position: refs/heads/master@{#36001}

[adamk, 2016-04-28 21:48:46]

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

[adamk, 2016-04-28 21:48:46]

It didn't appear to me that Crankshaft was affected by this change (it already
explicitly calls its accessor function_language_mode()), but correct me if I'm
wrong.

[adamk, 2016-04-29 22:49:51]

Description was changed from

==========
Compiler backends should derive language mode from current Scope

This allows proper handling of the strictness of class declarations
and expressions. In particular, the extends expression is in strict
mode, even if the surrounding function is sloppy.

BUG=v8:4970
LOG=n
==========

to

==========
Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval (see regress-4974.js for such a case
that crashes without this part of the patch).

BUG=v8:4970
LOG=n
==========

[adamk, 2016-04-29 22:49:51]

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

[adamk, 2016-04-29 22:50:01]

Description was changed from

==========
Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval (see regress-4974.js for such a case
that crashes without this part of the patch).

BUG=v8:4970
LOG=n
==========

to

==========
Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval (see regress-4974.js for such a case
that crashes without this part of the patch).

BUG=v8:4970, v8:4974
LOG=n
==========

[adamk, 2016-04-29 22:55:05]

Added a fix for a very related bug to this patch.

[adamk, 2016-05-02 17:23:59]

On 2016/04/29 22:55:05, adamk wrote:
> Added a fix for a very related bug to this patch.

..and that test is now failing on ia32 with --verify-heap. Hmm....

[adamk, 2016-05-02 18:52:57]

On 2016/05/02 17:23:59, adamk wrote:
> On 2016/04/29 22:55:05, adamk wrote:
> > Added a fix for a very related bug to this patch.
> 
> ..and that test is now failing on ia32 with --verify-heap. Hmm....

It's failing while tearing down the Isolate. Somehow Heap::undefined_string (at
least that's the one that fails locally) has had its map pointer messed with.

[adamk, 2016-05-02 19:28:33]

On 2016/05/02 18:52:57, adamk wrote:
> On 2016/05/02 17:23:59, adamk wrote:
> > On 2016/04/29 22:55:05, adamk wrote:
> > > Added a fix for a very related bug to this patch.
> > 
> > ..and that test is now failing on ia32 with --verify-heap. Hmm....
> 
> It's failing while tearing down the Isolate. Somehow Heap::undefined_string
(at
> least that's the one that fails locally) has had its map pointer messed with.

Okay, 4974 is actually a Parser bug, I'm going to remove that test case from the
CL.

[adamk, 2016-05-02 19:29:20]

Description was changed from

==========
Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval (see regress-4974.js for such a case
that crashes without this part of the patch).

BUG=v8:4970, v8:4974
LOG=n
==========

to

==========
Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.

BUG=v8:4970
LOG=n
==========

[adamk, 2016-05-02 19:29:52]

The CQ bit was checked by adamk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-02 19:30:02]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1931003003/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1931003003/100001

[commit-bot: I haz the power, 2016-05-02 20:01:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-02 20:01:09]

Dry run: This issue passed the CQ dry run.

[Michael Starzinger, 2016-05-03 07:44:06]

mstarzinger@chromium.org changed reviewers:
+ mstarzinger@chromium.org

[Michael Starzinger, 2016-05-03 07:44:06]

LGTM on the compilers.

[adamk, 2016-05-03 18:08:29]

adamk@chromium.org changed reviewers:
+ littledan@chromium.org
- bmeurer@chromium.org, rossberg@chromium.org

[adamk, 2016-05-03 18:08:30]

+littledan for parser

[Dan Ehrenberg, 2016-05-03 21:09:05]

lgtm

[adamk, 2016-05-03 22:00:06]

The CQ bit was checked by adamk@chromium.org

[commit-bot: I haz the power, 2016-05-03 22:00:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1931003003/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1931003003/100001

[commit-bot: I haz the power, 2016-05-03 22:35:43]

Description was changed from

==========
Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.

BUG=v8:4970
LOG=n
==========

to

==========
Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.

BUG=v8:4970
LOG=n
==========

[commit-bot: I haz the power, 2016-05-03 22:35:44]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-05-03 22:36:39]

Description was changed from

==========
Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.

BUG=v8:4970
LOG=n
==========

to

==========
Fix 'eval' in class extends clauses to be always-strict

Compiler backends get their language mode from the current
function, but should instead be deriving it from the current scope.
This allows proper handling of the always-strictness of class declarations
and expressions, and in particular the treatment of 'eval' calls in an
extends clause as a strict eval.

Also fix the parser's RecordEvalCall logic to only reach out to the
DeclarationScope in sloppy mode, which fixes the strange case of a
sloppy function thinking it contains a sloppy eval when in fact
it contains only a strict eval.

BUG=v8:4970
LOG=n

Committed: https://crrev.com/c8a342a5825a835556e0ae26f8a1295b80d02489
Cr-Commit-Position: refs/heads/master@{#36001}
==========

[commit-bot: I haz the power, 2016-05-03 22:36:40]

Patchset 6 (id:??) landed as
https://crrev.com/c8a342a5825a835556e0ae26f8a1295b80d02489
Cr-Commit-Position: refs/heads/master@{#36001}