Strict mode assignment to undefined reference.

Strict mode assignment to undefined reference.
Simple assignments (x = <value>) use CODE_TARGET_CONTEXT.
StoreIC stores its own strictness in extra_ic_state.
The strcitness is propagated as further ic stubs are generated.

BUG=
TEST=es5conform, test/mjsunit/strict-mode.js

[Martin Maly, 2011-02-11 02:01:28]

Hi Mads,

I think the code is ready for the first look. The assignment to undefined global
doesn't appear to require crankshaft changes because the crankshaft will
deoptimize if deleted global is seen. I may very likely be missing something
there though.

Soren, I changed the way assignment to global is generated (CODE_TARGET_CONTEXT
instead of CODE_TARGET). This triggered debugger test which I fixed but changes
in the debugger may be needed, please let me know if/where I should look to fix
debugger if needed.

Thanks!
Martin

[MarkM, 2011-02-11 03:06:59]

http://codereview.chromium.org/6474026/diff/1/test/mjsunit/strict-mode.js
File test/mjsunit/strict-mode.js (right):

http://codereview.chromium.org/6474026/diff/1/test/mjsunit/strict-mode.js#new...
test/mjsunit/strict-mode.js:352: testAssignToUndefined(true);
Why are you calling this three times for each case?

[Mads Ager (chromium), 2011-02-11 08:08:09]

LGTM

This definitely seems like the right way of handling this. The ICs will bailout
if you are attempting to introduce a new global variable or if you are storing
to a deleted one. This seems like the right way to propagate the strict-mode and
contextual information to the runtime system. You are right that no changes are
needed to crankshaft code generators for this.

http://codereview.chromium.org/6474026/diff/1/test/mjsunit/strict-mode.js
File test/mjsunit/strict-mode.js (right):

http://codereview.chromium.org/6474026/diff/1/test/mjsunit/strict-mode.js#new...
test/mjsunit/strict-mode.js:352: testAssignToUndefined(true);
On 2011/02/11 03:06:59, MarkM wrote:
> Why are you calling this three times for each case?

In order to make sure that ICs are initialized and used, the first time through
the code the ICs are not yet initialized and everything is taken care of in the
runtime system.

Martin, can you put this in a loop and do it 10 times for each? That way we have
a bit more slack if we change the heuristics for when to generate new ICs and
patch the code.

[Søren Thygesen Gjesse, 2011-02-11 08:09:18]

LGTM, for the test-debug.cc change.

I don't think changes to the debugger is required for this as it just replaces
store ICs with debug break ICs, and I don't think the reloc info mode makes any
difference there.

[Martin Maly, 2011-02-11 21:43:28]

Thanks for the review! Fixed the test (added the loop tests) and committed.

http://codereview.chromium.org/6474026/diff/1/test/mjsunit/strict-mode.js
File test/mjsunit/strict-mode.js (right):

http://codereview.chromium.org/6474026/diff/1/test/mjsunit/strict-mode.js#new...
test/mjsunit/strict-mode.js:352: testAssignToUndefined(true);
On 2011/02/11 08:08:09, Mads Ager wrote:
> On 2011/02/11 03:06:59, MarkM wrote:
> > Why are you calling this three times for each case?
> 
> In order to make sure that ICs are initialized and used, the first time
through
> the code the ICs are not yet initialized and everything is taken care of in
the
> runtime system.
> 
> Martin, can you put this in a loop and do it 10 times for each? That way we
have
> a bit more slack if we change the heuristics for when to generate new ICs and
> patch the code.

Done.

[Martin Maly, 2011-02-13 16:23:34]

Fix to presubmit.

http://codereview.chromium.org/6474026/diff/12003/src/stub-cache.h
File src/stub-cache.h (right):

http://codereview.chromium.org/6474026/diff/12003/src/stub-cache.h#newcode628
src/stub-cache.h:628: explicit StoreStubCompiler(Code::ExtraICState
extra_ic_state)
Fixing presubmit.

[Martin Maly, 2011-02-13 16:43:10]

Fixing presubmit.