- 18 Nov, 2016 1 commit
-
-
marja authored
It originates from the era where we used to run a separate preparse step before parsing and store the function data. Now the usage of preparser is something completely different, so this flag doesn't make sense any more. In addition, this way we get more test coverage for preparser (for small scripts). BUG= Review-Url: https://codereview.chromium.org/2513563002 Cr-Commit-Position: refs/heads/master@{#41110}
-
- 13 Oct, 2016 1 commit
-
-
verwaest authored
I don't see a reason why we can't benefit from preparsing such functions. We don't necessarily compile them, so fully parsing them when unnecessary is just additional overhead. BUG=v8:5501 Review-Url: https://codereview.chromium.org/2413213002 Cr-Commit-Position: refs/heads/master@{#40248}
-
- 26 Jan, 2016 1 commit
-
-
adamk authored
ParseArrowFunctionLiteral was erroneously checking AllowsLazyCompilation rather than AllowsLazyParsing when deciding whether to parse lazily. This meant that lexically-scoped variables that had no other referents wouldn't get closed over properly. BUG=chromium:580934, v8:4255 LOG=y Review URL: https://codereview.chromium.org/1630823006 Cr-Commit-Position: refs/heads/master@{#33530}
-
- 14 Jan, 2016 1 commit
-
-
adamk authored
This avoids generating different scopes on the two compilation passes, which results in various delirious side-effects. There's some cleanup to be done in lazy arrow function parsing, but I'd rather do that in a separate patch, with this one targeted at fixing the particular crash. BUG=chromium:572589 LOG=n Review URL: https://codereview.chromium.org/1575333004 Cr-Commit-Position: refs/heads/master@{#33311}
-