Allocate block-scoped global bindings to global context.

Allocate block-scoped global bindings to global context.

- The global object has a reference to the current global scope chain.
  Running a script adds to the chain if it contains global lexical declarations.
- Scripts are executed relative to a global, not a native context.
- Harmony let and const bindings are allocated to the innermost global context;
  var and function still live on the global object.
  (Lexical bindings are not reflected on the global object at all,
  but that will probably change later using accessors, as for modules.)
- Compilation of scripts now needs a (global) context (previously only eval did).
- The global scope chain represents one logical scope, so collision tests take
  the chain into account.


R=svenpanne@chromium.org
BUG=

Committed: https://code.google.com/p/v8/source/detail?r=12398

[Sven Panne, 2012-08-28 07:35:00]

lgtm

http://codereview.chromium.org/10872084/diff/1/src/objects.cc
File src/objects.cc (right):

http://codereview.chromium.org/10872084/diff/1/src/objects.cc#newcode12005
src/objects.cc:12005: reinterpret_cast<CompilationCacheTable*>(obj);
Do we really need the reinterpret_cast here or would CompilationCacheTable::cast
work, too? If the latter works, using a templatized To would be better (probably
below, too, but there it doesn't really make a difference).

Another point: Removing the tiny scopes is a bad idea IMHO, one should keep the
scopes/lifetimes as small as possible to help readability. Furthermore, the tiny
scopes are a common v8 idiom.

http://codereview.chromium.org/10872084/diff/1/src/parser.cc
File src/parser.cc (right):

http://codereview.chromium.org/10872084/diff/1/src/parser.cc#newcode1805
src/parser.cc:1805: (mode != VAR && mode != CONST) ||
o_O

[rossberg, 2012-08-28 11:09:39]

https://chromiumcodereview.appspot.com/10872084/diff/1/src/objects.cc
File src/objects.cc (right):

https://chromiumcodereview.appspot.com/10872084/diff/1/src/objects.cc#newcode...
src/objects.cc:12005: reinterpret_cast<CompilationCacheTable*>(obj);
On 2012/08/28 07:35:00, Sven Panne wrote:
> Do we really need the reinterpret_cast here or would
CompilationCacheTable::cast
> work, too? If the latter works, using a templatized To would be better
(probably
> below, too, but there it doesn't really make a difference).

Indeed, it's not needed. Changed.

> Another point: Removing the tiny scopes is a bad idea IMHO, one should keep
the
> scopes/lifetimes as small as possible to help readability. Furthermore, the
tiny
> scopes are a common v8 idiom.

Yeah, in principle, I agree with you. Except that in C++, I have been so
conditioned to have all flags go up when I encounter a scope like that that I
find seeing one where no RAII hack is in play more irritating than helpful... ;)

https://chromiumcodereview.appspot.com/10872084/diff/1/src/parser.cc
File src/parser.cc (right):

https://chromiumcodereview.appspot.com/10872084/diff/1/src/parser.cc#newcode1805
src/parser.cc:1805: (mode != VAR && mode != CONST) ||
On 2012/08/28 07:35:00, Sven Panne wrote:
> o_O

You gotta love the beauty of semantic incoherence and backwards compatibility
hacks in our all's favorite language.