Skip to content

V
V8
Switch branch/tag
  1. 17 Oct, 2016 2 commits
  3. 14 Oct, 2016 1 commit
    • marja's avatar
      Remove "is function lazy" logic from Preparser + tiny error reporting refactoring. · 97fe83c7
      marja authored 
      It doesn't need to have this logic.

ParseLazyFunctionLiteralBody is basically just ParseStatementList
+ log the function position. But PreParser doesn't need to have
the "which functions to log" logic, since logging the function is
always done exactly when Parser falls back to PreParser. (See
PreParseLazyFunction.)

So in the current state, PreParser would log several functions in
a SingletonLogger, and only the last one would take
effect (that's the one Parser also logs in SkipLazyFunctionBody).

Also updated test-parsing/Regress928 to produce the preparse data
the way we do now (i.e., not running the PreParser directly, but
running the Parser).

Error reporting: when PreParser finds an error, it doesn't need
to ReportUnexpectedToken in PreParseLazyFunction, since it
already has reported the error whenever it found it.

BUG=v8:5515

Review-Url: https://codereview.chromium.org/2421833002
Cr-Commit-Position: refs/heads/master@{#40315}
      97fe83c7
  5. 13 Oct, 2016 1 commit
  7. 11 Oct, 2016 2 commits
  9. 07 Oct, 2016 1 commit
  11. 27 Sep, 2016 1 commit
  13. 26 Sep, 2016 2 commits
  15. 23 Sep, 2016 2 commits
    • neis's avatar
      [modules] Simplify treatment of empty imports. · f9e9a016
      neis authored 
      There's no reason (anymore) to have empty imports in special_imports.  Remove
them from there and rename special_imports to namespace_imports to be more
precise.

R=adamk@chromium.org
BUG=v8:1569

Review-Url: https://codereview.chromium.org/2368613002
Cr-Commit-Position: refs/heads/master@{#39693}
      f9e9a016
    • marja's avatar
      Fix test-parsing/InnerAssignment. · 83207f48
      marja authored 
      It looks like it tried to trigger lazy inner function parsing by
inserting a comment into an inner function.

1) We don't have lazy inner functions yet.
2) Even if we had, there's no way this heuristic could trigger laziness:
we need to do the laziness decision upfront, without looking at the
contents / size of the function.
3) Some of the combinations were weird: lazy_outer but non-lazy inner?

In the current heuristics, only the total script size affects laziness;
in particular, it doesn't matter where the long comment is.

R=mstarzinger@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2364003002
Cr-Commit-Position: refs/heads/master@{#39673}
      83207f48
  17. 20 Sep, 2016 1 commit
  19. 19 Sep, 2016 1 commit
    • neis's avatar
      [modules] Explicitly keep track of module requests. · c5785bfb
      neis authored 
      We must keep track of the exact order in which modules are requested.
To do so, maintain a map from module specifiers to position while
parsing (in ModuleDescriptor). Descriptor entries now refer to that
position rather than the string.  When generating the ModuleInfo, turn
this map into an array of specifiers. We don't need the map anymore
later on, so we do not reconstruct it when deserializing again.

BUG=v8:1569

Review-Url: https://codereview.chromium.org/2353633002
Cr-Commit-Position: refs/heads/master@{#39519}
      c5785bfb
  21. 16 Sep, 2016 2 commits
    • vogelheim's avatar
      Rework scanner-character-streams. · 642d6d31
      vogelheim authored 
      - Smaller, more consistent streams API (Advance, Back, pos, Seek)
- Remove implementations from the header, in favor of creation functions.

Observe:
- Performance:
  - All Utf16CharacterStream methods have an inlinable V8_LIKELY w/ a
    body of only a few instructions. I expect most calls to end up there.
  - There used to be performance problems w/ bookmarking, particularly
    with copying too much data on SetBookmark w/ UTF-8 streaming streams.
    All those copies are gone.
  - The old streaming streams implementation used to copy data even for
    2-byte input. It no longer does.
  - The only remaining 'slow' method is the Seek(.) slow case for utf-8
    streaming streams. I don't expect this to be called a lot; and even if,
    I expect it to be offset by the gains in the (vastly more frequent)
    calls to the other methods or the 'fast path'.
  - If it still bothers us, there are several ways to speed it up.
- API & code cleanliness:
  - I want to remove the 'old' API in a follow-up CL, which should mostly
    delete code, or replace it 1:1.
  - In a 2nd follow-up I want to delete much of the UTF-8 handling in Blink
    for streaming streams.
  - The "bookmark" is now always implemented (and mostly very fast), so we
    should be able to use it for more things.
- Testing & correctness:
  - The unit tests now cover all stream implementations,
    and are pretty good and triggering all the edge cases.
  - Vastly more DCHECKs of the invariants.

BUG=v8:4947

Review-Url: https://codereview.chromium.org/2314663002
Cr-Commit-Position: refs/heads/master@{#39464}
      642d6d31
    • bakkot's avatar
      Class fields, part 1 (parsing and infrastructure) · fe6b76d4
      bakkot authored 
      This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields

See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/

This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.

Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.

BUG=v8:5367

Review-Url: https://codereview.chromium.org/2315733003
Cr-Commit-Position: refs/heads/master@{#39459}
      fe6b76d4
  23. 15 Sep, 2016 2 commits
    • jochen's avatar
      Only pass the outer scope info with ParseInfo · 65aa596f
      jochen authored 
      We don't need the context anymore for parsing, the scope info chain is
enough.

BUG=v8:5215
R=marja@chromium.org,jgruber@chromium.org,mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2342443004
Cr-Commit-Position: refs/heads/master@{#39457}
      65aa596f
    • jochen's avatar
      Fully deserialize the scope chain after parsing, not before · 94492437
      jochen authored 
      To avoid a dependency on the heap during parsing, we only create a scope chain
without linking to the associated ScopeInfo objects before parsing. This is
enough to avoid special cases during parsing of arrow functions / eval.

Looking at the outer scope's variables during parsing was only needed for hosting
sloppy block functions inside eval. To be able to do this now, we hoist for the
outer-most eval scope after parsing, in DeclarationScope::Analyze.

DeclarationScope::Analyze is also where we replace the outer scope chain with the
fully deserialized version, so variables can be resolved.

Also, this unifies background and foreground thread parsing, as we don't have to
worry about ScopeInfos getting accessed before we're back on the main thread.

BUG=v8:5215
R=verwaest@chromium.org,marja@chromium.org,adamk@chromium.org

Review-Url: https://codereview.chromium.org/2306413002
Cr-Commit-Position: refs/heads/master@{#39452}
      94492437
  25. 07 Sep, 2016 1 commit
  27. 02 Sep, 2016 1 commit
  29. 01 Sep, 2016 1 commit
  31. 31 Aug, 2016 3 commits
  33. 30 Aug, 2016 1 commit
  35. 26 Aug, 2016 1 commit
  37. 25 Aug, 2016 2 commits
    • adamk's avatar
      Centralize and standardize logic for ExpressionClassifier accumulation · 51c186dd
      adamk authored 
      Previously the calls to ExpressionClassifier::Accumulate() each chose
slightly different sets of productions to accumulate, and it turned
out that these were in some cases broader than needed and in some
cases less broad.

The existence of some grab-bag production bitmasks like
ExpressionClassifier::ExpressionProductions made this situation more
error-prone (for example, that production was missing AsyncArrowFormalParametersProduction).

This patch removes all "grab-bags" besides AllProductions. In some of
the places where code was using those grab-bags for convenience, it
switches them to use negation of AllProductions. In other, specifically
those having to do with expressions that are disallowed anywhere in
a sub-expression of a parameter list, I've added a new method on
ExpressionClassifier to centralize the logic.

The aforementioned centralization/addition of
AsyncArrowFormalParametersProduction fixes several cases where we were
failing to report an error for 'await' in some contexts; I've added
those test cases.

The patch also narrows all cases to exactly the set or productions
necessary, with a comment on each explaining the choice.

BUG=v8:4483

Review-Url: https://codereview.chromium.org/2271063002
Cr-Commit-Position: refs/heads/master@{#38918}
      51c186dd
    • neis's avatar
      [modules] Split exports into regular and special, store regular ones in a multimap. · 6e67d042
      neis authored 
      BUG=v8:1569

Review-Url: https://codereview.chromium.org/2273013002
Cr-Commit-Position: refs/heads/master@{#38889}
      6e67d042
  39. 23 Aug, 2016 5 commits
  41. 22 Aug, 2016 3 commits
    • adamk's avatar
      [async functions] Disallow 'await' in arrow params inside async functions · 232a3360
      adamk authored 
      The following code was previously accepted:

  async function f() {
    let g = (await) => {};
  }

But per the spec, using 'await' is disallowed in arrow parameters
by an early error rule (just as 'yield' is disallowed in arrow
params inside generators).

There was special logic in ParseUnaryExpression which seems to have been
there only to allow that case. Having removed it, we get a SyntaxError in
the right cases anyway when ParseUnaryExpression chokes on whatever
illegal token follows 'await' in the cases this code previously handled.

Also removes the unnecessary AsyncBindingPatternProduction enum value.

R=caitp@igalia.com, littledan@chromium.org
BUG=v8:4483

Review-Url: https://codereview.chromium.org/2258313002
Cr-Commit-Position: refs/heads/master@{#38802}
      232a3360
    • adamk's avatar
      Disallow 'await' in object literal shorthand position · 253d4e84
      adamk authored 
      Also lots of cleanup around the checking for 'await' as an identifier
throughout the parser and preparser.

R=caitp@igalia.com, littledan@chromium.org
BUG=v8:4483,v8:5298

Review-Url: https://codereview.chromium.org/2267493002
Cr-Commit-Position: refs/heads/master@{#38798}
      253d4e84
    • marja's avatar
      Cleanup: Move ParseInfo to a separate file. · f9d60761
      marja authored 
      This makes us able to get rid of dependencies to parser.h from places
which only need the ParseInfo, and also gets rid of the curious Parser
<-> Compiler circular dependency.

Also IWYUd where necessary.

BUG=

Review-Url: https://codereview.chromium.org/2268513002
Cr-Commit-Position: refs/heads/master@{#38777}
      f9d60761
  43. 20 Aug, 2016 1 commit
    • gsathya's avatar
      [parser] Allow duplicate __proto__ keys in patterns · fc52e323
      gsathya authored 
      This patch subsumes CoverInitializedNameProduction to create an ObjectLiteralProduction which is now used to report the duplicate proto error as well.

This patch also changes ObjectLiteralChecker::CheckProperty
to record an ObjectLiteralProduction error instead of
bailing out immediately. Once we realize that we're in a
pattern, we rewind the error, otherwise we report the
error.

BUG=v8:5121

Review-Url: https://codereview.chromium.org/2255353002
Cr-Commit-Position: refs/heads/master@{#38764}
      fc52e323
  45. 19 Aug, 2016 1 commit
  47. 18 Aug, 2016 1 commit
  49. 17 Aug, 2016 1 commit
    • vogelheim's avatar
      Scanner::LiteralBuffer usage cleanup. · c677f813
      vogelheim authored 
      1, restrict use of LiteralBuffers to the tokens that actually need it.
  - E.g., previously the Token::FUNCTION would have a literal buffer
    containing "function", which was never actually used.
  - This eliminates copies of the string data for every call to
    PeekAhead or SetBookmark.
2, document & enforce the "secret" Scanner API contract w/ DCHECK
  - Document & check the correspondence of token value and literal buffer.
  - Document & check preconditions for calling PeekAhead, ScanRegExp*,
    ScanTemplate*.

BUG=v8:4947

Review-Url: https://codereview.chromium.org/2240513003
Cr-Commit-Position: refs/heads/master@{#38677}
      c677f813