This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.
No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
We needed to change/remove the cctests that used to check
something on this list.
Working in x64, ia32, arm64, arm, mips64 and mips.
Bug: v8:6637
Change-Id: Ica99a12fd0351ae985e9a287918bf28caf6d2e24
TBR: mstarzinger@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/647596
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47808}
This reverts commit 84c2dfce43.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876
Original change's description:
> Remove weak-list of optimized JS functions.
>
> This CL removes the weak-list of JS functions from the context
> and all the code that iterares over it. This list was being used
> mainly during deoptimization (for code unlinking) and during
> garbage collection. Removing it will improve performance of
> programs that create many closures and trigger many scavenge GC
> cycles.
>
> No extra work is required during garbage collection. However,
> given that we no longer unlink code from JS functions during
> deoptimization, we leave it as it is, and on its next activation
> we check whether the mark_for_deoptimization bit of that code is
> set, and if it is, than we unlink it and jump to lazy compiled
> code. This check happens in the prologue of every code object.
>
> We needed to change/remove the cctests that used to check
> something on this list.
>
> Working in x64, ia32, arm64, arm, mips64 and mips.
>
> Bug: v8:6637
> Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
> Reviewed-on: https://chromium-review.googlesource.com/600427
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47790}
TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6637
Reviewed-on: https://chromium-review.googlesource.com/647540
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47792}
This CL removes the weak-list of JS functions from the context
and all the code that iterares over it. This list was being used
mainly during deoptimization (for code unlinking) and during
garbage collection. Removing it will improve performance of
programs that create many closures and trigger many scavenge GC
cycles.
No extra work is required during garbage collection. However,
given that we no longer unlink code from JS functions during
deoptimization, we leave it as it is, and on its next activation
we check whether the mark_for_deoptimization bit of that code is
set, and if it is, than we unlink it and jump to lazy compiled
code. This check happens in the prologue of every code object.
We needed to change/remove the cctests that used to check
something on this list.
Working in x64, ia32, arm64, arm, mips64 and mips.
Bug: v8:6637
Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3
Reviewed-on: https://chromium-review.googlesource.com/600427
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47790}
This code appears to have been wrong forever, as it only
threw in strict mode (presumably predating ES2015 const).
In order to get exactly the right behavior, special
handling of sloppy named function expressions is required.
Rather than polluting PropertyAttributes with another
dummy value, this CL simply adds a bool output argument
to Context::Lookup to indicate that case.
Bug: v8:6677
Change-Id: I34daa5080d291808f10cbaefc91d716f0b22963b
Reviewed-on: https://chromium-review.googlesource.com/602690
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47207}
There are very few cases where OSR code can be re-used, and where the
function won't be non-concurrently optimized after OSR has happened.
Maintaining the OSR code cache is unnecessary complexity, and caching
OSR prevents us from e.g. seeding the optimizer with the actual OSR
values.
So, this patch removes it.
Change-Id: Ib9223de590f35ffc1dc2ab593b7cc9fe97dde4a6
Reviewed-on: https://chromium-review.googlesource.com/552637
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46306}
Only FullCodegen code ever gets flushed by code flushing. Since we are
deprecating the old pipeline, the added complexity introduced by code
flushing is no longer worth it. This CL removes it (but keeps code aging,
which is used to unlink SFIs from the compilation cache).
BUG=v8:6389,v8:6379,v8:6409
Change-Id: I90de113a101f86dbeaaf0511c61a090ef12aa365
Reviewed-on: https://chromium-review.googlesource.com/507388
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45446}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246,chromium:718891
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6
Reviewed-on: https://chromium-review.googlesource.com/500134
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45234}
This reverts commit 662aa425ba.
Reason for revert: Crashing on Canary
BUG=chromium:718891
Original change's description:
> Reland: [TypeFeedbackVector] Store optimized code in the vector
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> BUG=v8:6246
> TBR=yangguo@chromium.org,ulan@chromium.org
>
> Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
> Reviewed-on: https://chromium-review.googlesource.com/494487
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45084}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6246
Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
Reviewed-on: https://chromium-review.googlesource.com/498633
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45174}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
Reviewed-on: https://chromium-review.googlesource.com/494487
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45084}
This reverts commit c5ad9c6d8e.
Reason for revert: Fails on gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661
Original change's description:
> [TypeFeedbackVector] Store optimized code in the vector
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> BUG=v8:6246
>
> Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
> Reviewed-on: https://chromium-review.googlesource.com/476891
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45022}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6246
Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619
Reviewed-on: https://chromium-review.googlesource.com/493287
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45027}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
Reviewed-on: https://chromium-review.googlesource.com/476891
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45022}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2620753003
Cr-Original-Commit-Position: refs/heads/master@{#42258}
Committed: 3188780410
Review-Url: https://codereview.chromium.org/2620753003
Cr-Commit-Position: refs/heads/master@{#42264}
Reason for revert:
gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/8105
also on mac
Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2620753003
> Cr-Commit-Position: refs/heads/master@{#42258}
> Committed: 3188780410TBR=bmeurer@chromium.org,mstarzinger@chromium.org,yangguo@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2626863004
Cr-Commit-Position: refs/heads/master@{#42260}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2620753003
Cr-Commit-Position: refs/heads/master@{#42258}
Reason for revert:
Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/
Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2504153002
> Cr-Commit-Position: refs/heads/master@{#41893}
> Committed: 93df094081TBR=bmeurer@chromium.org,mlippautz@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2597163002
Cr-Commit-Position: refs/heads/master@{#41917}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
eval() may introduce a scope which needs to be represented as a context at
runtime, e.g.,
eval('var x; let y; ()=>y')
introduces a variable y which needs to have a context allocated for it. However,
when traversing upwards to find the declaration context for a variable which leaks,
as the declaration of x does above, this context has to be understood to not be
a declaration context in sloppy mode.
This patch makes that distinction by introducing a different map for eval-introduced
contexts. A dynamic search for the appropriate context will continue past an eval
context to find the appropriate context. Marking contexts as eval contexts rather
than function contexts required updates in each compiler backend.
BUG=v8:5295, chromium:648719
Review-Url: https://codereview.chromium.org/2435023002
Cr-Commit-Position: refs/heads/master@{#41869}
Aside from the default snapshot, there is no need for additional context
snapshots to have the ability to replace the global proxy and global object
after deserialization. Changes include:
- Changes to the API to better distinguish default context snapshot from
additional context snapshots.
- Disallow global handles when creating snapshots.
- Allow extensions when creating snapshots.
This solves the issue of not being able to having accessors and interceptors on
the global object of contexts to be serialized.
R=jochen@chromium.org, peria@chromium.org
BUG=chromium:617892
Review-Url: https://codereview.chromium.org/2557743003
Cr-Commit-Position: refs/heads/master@{#41588}
The patch was reverted due to a bug - we failed to evict OSR-optimized
code in the case where the SharedFunctionInfo OptimizedCodeMap was
empty/cleared.
Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.
Review-Url: https://codereview.chromium.org/2561083002
Cr-Commit-Position: refs/heads/master@{#41584}
Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.
BUG=
Review-Url: https://codereview.chromium.org/2549753002
Cr-Commit-Position: refs/heads/master@{#41554}
This patch ensures that variables like .new_target aren't overwritable
using with scopes. It does this by ensuring that scope analysis does
not consider with scopes (or eval scopes) for such 'synthetic variables',
similarly to how the 'this' variable was already handled.
The patch also adds a DCHECK for the dynamic parallel to this case,
replacing a previous unreachable path for a particular instance.
BUG=v8:5405
Review-Url: https://codereview.chromium.org/2353623002
Cr-Commit-Position: refs/heads/master@{#39567}
Rename JSModule to Module and make it a Struct rather than a JSObject. We will
later add a separate JSModuleNamespace object to implement the 'import * as foo'
syntax.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2345823002
Cr-Commit-Position: refs/heads/master@{#39477}
This adds partial support of exports to the runtime system and
to the interpreter. It introduces a new HeapObject JSModule that
maps each of the module's export names to a Cell containing the
exported value.
Several aspects of this implementation are subject to change in
follow-up CLs.
BUG=v8:1569
Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17
Review-Url: https://codereview.chromium.org/2302783002
Cr-Original-Commit-Position: refs/heads/master@{#39341}
Cr-Commit-Position: refs/heads/master@{#39352}
Rework Runtime::FunctionForName to take a c-string instead of a v8::String
so that the parser can parse native syntax runtime calls without doing
on-the-fly internalization.
Also adds a c-string variant of IntrinsicIndexForName for the same reasons.
BUG=v8:5215,chromium:634953
Review-Url: https://codereview.chromium.org/2324803002
Cr-Commit-Position: refs/heads/master@{#39346}
Reason for revert:
Failures related to deopt.
Original issue's description:
> [modules] Basic support of exports
>
> This adds partial support of exports to the runtime system and
> to the interpreter. It introduces a new HeapObject JSModule that
> maps each of the module's export names to a Cell containing the
> exported value.
>
> Several aspects of this implementation are subject to change in
> follow-up CLs.
>
> BUG=v8:1569
>
> Committed: https://crrev.com/241a0412eed919395a2e163b30b9b66071ce5c17
> Cr-Commit-Position: refs/heads/master@{#39341}
TBR=adamk@chromium.org,rmcilroy@chromium.org,ulan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2328283002
Cr-Commit-Position: refs/heads/master@{#39345}
This adds partial support of exports to the runtime system and
to the interpreter. It introduces a new HeapObject JSModule that
maps each of the module's export names to a Cell containing the
exported value.
Several aspects of this implementation are subject to change in
follow-up CLs.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2302783002
Cr-Commit-Position: refs/heads/master@{#39341}
This will allow getting the entire scope chain from a SharedFunctionInfo
which in turn will allow for generating bytecode when we just have the
SFI
R=verwaest@chromium.org,marja@chromium.org
BUG=v8:5215
Review-Url: https://codereview.chromium.org/2271993002
Cr-Commit-Position: refs/heads/master@{#39243}
This will allow for chaining ScopeInfos together to form the same chains
as contexts chains currently do.
BUG=v8:5215
R=mstarzinger@chromium.org,marja@chromium.org,bmeurer@chromium.org,rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2314483002
Cr-Commit-Position: refs/heads/master@{#39192}
Since the extension field is already used for the catch name, store a
ContextExtension there instead.
In the future, this will allow for chaining ScopeInfos together, so we
no longer need a context chain for lazy parsing / compilation.
BUG=v8:5215
R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org
Review-Url: https://codereview.chromium.org/2302013002
Cr-Commit-Position: refs/heads/master@{#39164}
The plan is to also use it for With and Catch scopes, so all kinds of
contexts have a pointer back to their ScopeInfo
R=neis@chromium.org,marja@chromium.org
BUG=v8:5215
Review-Url: https://codereview.chromium.org/2301913002
Cr-Commit-Position: refs/heads/master@{#39092}
The only remaining use of this VariableMode is for the names of sloppy
named function expressions. This patch instead uses CONST for such
bindings (just as we do in strict mode) and instead marks those
Variables specially. During code generation a new helper method,
Variable::throw_on_const_assignment(), is called to decide whether
to throw or silently ignore the assignment.
Review-Url: https://codereview.chromium.org/2233673003
Cr-Commit-Position: refs/heads/master@{#39052}
This additionally gets rid of old approach to global shortcuts.
BUG=v8:5209
Review-Url: https://codereview.chromium.org/2287173002
Cr-Commit-Position: refs/heads/master@{#38980}
They may have once been different, but they're now redundant with
each other. This simplifies both Context::Lookup and its callers.
Review-Url: https://codereview.chromium.org/2200303002
Cr-Commit-Position: refs/heads/master@{#38261}
This was being allowed due to the use of BindingFlags instead of VariableMode
to determine whether a looked-up binding was lexical. Because function
declarations are hoisted, they never need hole checks, and so were being
miscategorized as non-lexical.
This patch augments Context::Lookup with a VariableMode out param, which
allows this check to determine precisely whether the binding is lexical.
BUG=v8:4454, v8:5256
Review-Url: https://codereview.chromium.org/2206483004
Cr-Commit-Position: refs/heads/master@{#38260}
Highlights:
- Record all imports and exports in the ModuleDescriptor.
- Remove ImportDeclaration; instead, introduce a new variable kind for imports.
- Set name on default exported anonymous functions.
Still to do: declaration of namespace imports.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2108193003
Cr-Commit-Position: refs/heads/master@{#37815}
