Skip to content

V
V8
Switch branch/tag
  1. 17 Mar, 2017 1 commit
  3. 15 Mar, 2017 1 commit
  5. 14 Mar, 2017 1 commit
  7. 20 Feb, 2017 1 commit
  9. 16 Feb, 2017 2 commits
  11. 10 Feb, 2017 1 commit
  13. 08 Feb, 2017 1 commit
  15. 07 Feb, 2017 3 commits
  17. 06 Feb, 2017 1 commit
  19. 03 Feb, 2017 2 commits
  21. 01 Feb, 2017 1 commit
    • adamk's avatar
      [parser] Remove hoist_scope from DeclarationDescriptor · 59b8496c
      adamk authored 
      The hoist_scope member of DeclarationDescriptor was only used to pass the function
scope for declaration of parameters containing sloppy evals, for example:

  function f(x = eval("var y")) { }

In cases like this, "x" is declared in the function scope but "y" is declared in an inner scope.
Rather than passing the function scope as "hoist_scope", we simply ask for the outer_scope()
of the inner scope as needed in PatternRewriter.

This reduces the cognitive overhead of understanding what a DeclarationDescriptor has; for
example, it removes some dead code from the PreParser which never has to deal
with a situation like the example above.

Review-Url: https://codereview.chromium.org/2662183002
Cr-Commit-Position: refs/heads/master@{#42861}
      59b8496c
  23. 26 Jan, 2017 1 commit
    • marja's avatar
      [parser] Skipping inner funcs: add info about variables. · d4507a6c
      marja authored 
      - Declaring a variable called "this" for preparsed functions was unnecessary;
  DeclarationScope ctor already adds the variable.

- "arguments" for preparsed scopes need to be declared after parsing the
  function, like it's done in the parser.

- Now arguments_ can be the dummy variable, so adapted code to it.

- A previous refactoring CL ( https://codereview.chromium.org/2638333002 ) was
  incomplete; it had added ParserBase::ParseFunctionBody but
  PreParser::ParseFunction didn't call it. This CL completes that work. This is
  needed for getting "arguments" declared properly for preparsed functions.

- AllocateVariablesRecursively is already called for preparsed scopes (without
  this CL, that is), and it bails out early. However, before the bailout it used
  to dcheck num_stack_slots_ == 0; that is no longer true since we've done scope
  analysis for preparsed scopes.

- Test fix: we cannot have any lazy inner functions in the test, except the
  topmost lazy inner function. Such functions would also be lazy in the parser
  case, and the parser would just throw away their variables. Then the test
  tries to verify the preparsed data against the scopes without variables and fails.

- Disabled a test w/ a sloppy block function, will get that working again in the
  upcoming CLs.

BUG=v8:5516

Review-Url: https://codereview.chromium.org/2655623005
Cr-Commit-Position: refs/heads/master@{#42685}
      d4507a6c
  25. 16 Jan, 2017 1 commit
  27. 10 Jan, 2017 1 commit
  29. 19 Dec, 2016 1 commit
  31. 12 Dec, 2016 1 commit
  33. 07 Dec, 2016 2 commits
  35. 06 Dec, 2016 1 commit
  37. 02 Dec, 2016 1 commit
  39. 01 Dec, 2016 1 commit
  41. 28 Nov, 2016 1 commit
    • jochen's avatar
      Assign unique IDs to FunctionLiterals · cfebe603
      jochen authored 
      They're supposed to be stable across several parse passes, so we'll also
store them in the associated SharedFunctionInfos

To achieve this, the PreParser and Parser need to generated the same number of
FunctionLiterals. To achieve this, we teach the PreParser about desuggaring of
class literals.

For regular functions, the function IDs are assigned in the order they occur in
the source. For arrow functions, however, we only know that it's an arrow function
after parsing the parameter list, and so the ID assigned to the arrow function is
larger than the IDs assigned to functions defined in the parameter list. This
implies that we have to reset the function ID counter to before the parameter list
when re-parsing an arrow function. To be able to do this, we store the number of
function literals found in the parameter list of arrow functions as well.

BUG=v8:5589

Review-Url: https://codereview.chromium.org/2481163002
Cr-Commit-Position: refs/heads/master@{#41309}
      cfebe603
  43. 22 Nov, 2016 1 commit
    • marja's avatar
      Preparse inner functions: fix maybe_assigned · d2e90c5d
      marja authored 
      ... but be less pessimistic about context allocation (see below).

We might have just (pessimistically) context-allocated a variable based
on references coming from an inner function, but after that we still
need to set maybe_assigned (pessimistically).

This makes test-parsing/InnerAssignment pass with
FLAG_lazy_inner_functions.

This was undetected until now because we didn't have lazy parsing enabled
for small scripts.

Less pessimistic approach: now that inner functions laziness decisions
are stable (if we have once compiled a piece of code with lazy inner
functions, we never compile the same code with eager inner functions),
we don't need to be as pessimistic with context allocation as before.

BUG=v8:5501

Review-Url: https://codereview.chromium.org/2521513004
Cr-Commit-Position: refs/heads/master@{#41183}
      d2e90c5d
  45. 17 Nov, 2016 1 commit
  47. 16 Nov, 2016 2 commits
  49. 15 Nov, 2016 2 commits
  51. 07 Nov, 2016 1 commit
    • verwaest's avatar
      [parser] Give preparser and parser independent loggers · 32105d21
      verwaest authored 
      This
- removes the ParserRecorder base class,
- devirtualizes the LogFunction and LogMessage functions,
- reuses the SingletonLogger for all preparser calls

In a subsequent step the preparser should probably log directly to the CompleteParserRecorder rather than indirectly through the singleton logger...

BUG=

Review-Url: https://codereview.chromium.org/2474393003
Cr-Commit-Position: refs/heads/master@{#40803}
      32105d21
  53. 04 Nov, 2016 1 commit
    • verwaest's avatar
      Preparse lazy function parameters · 4ff2cafe
      verwaest authored 
      Parameters of a lazily parsed function used to be parsed eagerly, and parameter
handling was split between Parser::ParseFunctionLiteral and
ParseEagerFunctionBody, leading to inconsistencies.

After this CL, we preparse (lazy parse) the parameters of lazily parsed
functions.

(For arrow functions, we cannot do that ofc.)

This is needed for later features (PreParser with scope analysis).

-- CL adapted from marja's https://codereview.chromium.org/2411793003/

BUG=

Review-Url: https://codereview.chromium.org/2472063002
Cr-Commit-Position: refs/heads/master@{#40771}
      4ff2cafe
  55. 25 Oct, 2016 1 commit
  57. 18 Oct, 2016 1 commit
  59. 14 Oct, 2016 2 commits
    • verwaest's avatar
      Drop Lazy from parser method names and events · 7899fcc5
      verwaest authored 
      BUG=

Review-Url: https://codereview.chromium.org/2414383002
Cr-Commit-Position: refs/heads/master@{#40318}
      7899fcc5
    • 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
  61. 10 Oct, 2016 1 commit
  63. 04 Oct, 2016 1 commit