This is done using desugaring. Before this we had:
result = iterator.next()
with this we instead do:
!%_IsSpecObject(result = iterator.next()) &&
%ThrowIteratorResultNotAnObject(result)
BUG=v8:3916
LOG=N
Review URL: https://codereview.chromium.org/929733003
Cr-Commit-Position: refs/heads/master@{#26805}
Add() becomes AddLocalExport, which takes an export_name and a local_name.
New parsing tests exercise this.
Also start generating exports for default exports (though this doesn't yet
handle anonymous default exports).
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/934323004
Cr-Commit-Position: refs/heads/master@{#26758}
It doesn't do anything for now, but it implies strict mode. Added tests to
test-parsing.cc to test that.
BUG=
Review URL: https://codereview.chromium.org/898983002
Cr-Commit-Position: refs/heads/master@{#26460}
The approach taken in this CL is to incrementally move toward the
currently-specced version of modules in ES6. The biggest change in this
patch is separating the parsing of modules from the parsing of scripts,
getting rid of the 'module' keyword and thus disallowing modules-in-scripts
as well as modules-in-modules.
The syntax supported by import/export declarations has not yet been significantly
changed, with the major exception being that import declarations require a string
as the 'from' part.
Most of the existing tests have been disabled, with a first new test added
in cctest/test-parsing.
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/881623002
Cr-Commit-Position: refs/heads/master@{#26299}
The bug has always been there: when the parser is operating in the "immediately
internalize" mode and calls GetString, we get FlatContent of a string and then
do heap allocation.
The bug was uncovered by https://codereview.chromium.org/693803004/ (which put
the parser to the "immediately internalize" mode more often), but looking at the
code, it's possible that it can happen in other cases too.
This CL makes AstValueFactory handle this situation gracefully: it won't try to
internalize inside GetString(Handle<String>); it's unnecessary anyway since we
have the Handle<String> already.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/706533005
Cr-Commit-Position: refs/heads/master@{#25179}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25179 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The bug has always been there: when the parser is operating in the "immediately
internalize" mode and calls GetString, we get FlatContent of a string and then
do heap allocation.
The bug was uncovered by https://codereview.chromium.org/693803004/ (which put
the parser to the "immediately internalize" mode more often), but looking at the
code, it's possible that it can happen in other cases too.
This CL makes AstValueFactory handle this situation gracefully: it won't try to
internalize inside GetString(Handle<String>); it's unnecessary anyway since we
have the Handle<String> already.
R=rossberg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/699343004
Cr-Commit-Position: refs/heads/master@{#25155}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25155 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
They were not, so we were creating several instances of them, one for each time
they occurred in the source code.
It's not known to have caused efficiency problems though, so this is a sanity
fix more than an efficiency fix.
Note that numbers are still not unique.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/657893003
Cr-Commit-Position: refs/heads/master@{#24873}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24873 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This adds flags in Scope to track wheter a Scope uses "this" and,
"arguments". The information is exposed via Scope::uses_this(),
and Scope::uses_arguments(), respectively. Flags for tracking
usage on any inner scope uses are available as well via
Scope::inner_uses_this(), and Scope::inner_uses_arguments().
Knowing whether scopes use "this" and "arguments" will be handy
to generate the code needed to capture their values when generating
the code for arrow functions.
BUG=v8:2700
LOG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/422923004
Patch from Adrian Perez de Castro <aperez@igalia.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
