ModuleDescriptor will end up holding the set of data described in the
spec as a "Module record". This introduces a little bit of confusion
with ModuleInfo, but I hope that'll become clearer over time.
Also removed the interface-printing flags. We probably want
Module-printing flags, but that can wait until we have more
Module-related structures.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/935723004
Cr-Commit-Position: refs/heads/master@{#26728}
This gets Variable and VariableProxy out of the business of worrying about
Interfaces.
At the same time, get rid of the notion of "module variables". In ES6, variables
that refer to modules will be simply be CONST bindings to module namespace
objects.
The only change in logic here is one more early error:
duplicate export names are now rejected.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/918373002
Cr-Commit-Position: refs/heads/master@{#26708}
This CL fixes tests that no longer valid and also fixes two issues:
1. 'super()' in non derived constructors.
2. Failure to step into derived constructors.
R=arv@chromium.org, yurys@chromium.org
BUG=v8:3834
LOG=Y
Review URL: https://codereview.chromium.org/923443003
Cr-Commit-Position: refs/heads/master@{#26628}
Scope, like Parser, must be able to operate independent of Isolate and the V8
heap (for background parsing). After the heap-independent phase, there is a heap
dependent phase, during which we do operations such as scope anaylysis.
This CL makes the phases explicit by not telling Scope about the Isolate too
early (during the heap-independent phase, Scope should know nothing about
Isolate). This decreases the probability of accidental code changes which would
add heap-dependent operations into the heap-independent phase.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/909093003
Cr-Commit-Position: refs/heads/master@{#26546}
This adds an "experimental" API hook (v8::ScriptCompiler::CompileModule)
allowing compilation of modules. The code gen is incredibly basic: the
module body is represented by a Block in the AST. But this at least gets
more of the pipeline working, and opens the door to writing mjsunit tests
(once d8 is modified to support module compilation).
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/902093002
Cr-Commit-Position: refs/heads/master@{#26496}
This enables adding more language modes in the future.
For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
use a sequence of language modes which are progressively stricter, but we can
express the language mode as combination of features.
For now, LanguageMode can only be "sloppy" or "strict", and there are
STATIC_ASSERTS in places which need to change when more modes are added.
LanguageMode is a bit like the old LanguageMode when "extended" mode was still
around (see https://codereview.chromium.org/8417035 and
https://codereview.chromium.org/181543002 ) except that it's transmitted through
all the layers (there's no StrictModeFlag).
BUG=
Review URL: https://codereview.chromium.org/894683003
Cr-Commit-Position: refs/heads/master@{#26419}
Along the way:
- Thread isolate parameter explicitly through code that used to
rely on getting it from the zone.
- Canonicalize the parameter position of isolate and zone for
affected code
- Change Hydrogen New<> instruction templates to automatically
pass isolate
R=mstarzinger@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/868883002
Cr-Commit-Position: refs/heads/master@{#26252}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, 7d48fd9dc2.
BUG=v8:3754
LOG=Y
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/798243004
Cr-Commit-Position: refs/heads/master@{#26084}
Reason for revert:
[sheriff] Still crashes on win32 (XP):
http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%201/builds/1380
Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0f4.
>
> This changes to do an early bailout in
> HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
> loop.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.orgTBR=dslomov@chromium.org,arv@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754
Review URL: https://codereview.chromium.org/811593004
Cr-Commit-Position: refs/heads/master@{#25872}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, a76419f0f4.
This changes to do an early bailout in
HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
loop.
BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/792233008
Cr-Commit-Position: refs/heads/master@{#25868}
Reason for revert:
Crashes Win32. It was not flake.
Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0f4 with
> no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
> try again.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.orgTBR=dslomov@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754
Review URL: https://codereview.chromium.org/807033003
Cr-Commit-Position: refs/heads/master@{#25853}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, a76419f0f4 with
no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
try again.
BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/807173002
Cr-Commit-Position: refs/heads/master@{#25851}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
BUG=v8:3754
LOG=Y
Review URL: https://codereview.chromium.org/795573005
Cr-Commit-Position: refs/heads/master@{#25821}
Named class declarations and class expression have a const binding for
the name that is in TDZ for the extends expression.
BUG=v8:3330
LOG=Y
R=dslomov@chromium.org, adamk
Review URL: https://codereview.chromium.org/722793005
Cr-Commit-Position: refs/heads/master@{#25360}
Reason for revert:
It broke layout test fast/events/window-onerror-02.html, error column reported by window.onerror is now wrong (I believe it is because of the change in full-codegen):
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/652
Original issue's description:
> Extend CPU profiler with mapping ticks to source lines
>
> The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
> During generation code and relocation info are generated simultaneously.
> When code generation is done you each code object has associated "relocation info".
> Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
> correspondences between the machine program counter and source locations for stack walking.
>
> This patch:
> 1. Add more source positions info in reloc info to make it suitable for source level mapping.
> The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
> (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
> I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
>
> 2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
> If a source line is found that hit counter is increased by one for this line.
>
> 3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
> Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
>
> 4.Add a test that checks how the samples are distributed through source lines.
> It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
>
> Patch from Denis Pravdin <denis.pravdin@intel.com>
> BUG=None
> LOG=Y
> R=svenpanne@chromium.org
>
> Committed: https://code.google.com/p/v8/source/detail?r=24389TBR=svenpanne@chromium.org,danno@chromium.org,alph@chromium.org,denis.pravdin@intel.com,weiliang.lin@intel.com
BUG=None
LOG=N
Review URL: https://codereview.chromium.org/624443005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24394 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
Patch from Denis Pravdin <denis.pravdin@intel.com>
BUG=None
LOG=Y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/616963005
Patch from Denis Pravdin <denis.pravdin@intel.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
