1. 12 May, 2022 1 commit
  2. 09 May, 2022 1 commit
  3. 03 Mar, 2022 1 commit
  4. 24 Jan, 2022 1 commit
    • Joyee Cheung's avatar
      Reland "[class] implement reparsing of class instance member initializers" · 0e07eb53
      Joyee Cheung authored
      This is a reland of 91f08378
      
      When the class scope does not need a context, the deserialized
      outer scope of the initializer scope would not be the class scope,
      and we should not and do not need to use it to fix up the allocation
      information of the context-allocated variables. The original patch
      did not consider this case and resulted in a regression when we
      tried to reparse the initializer function to look for destructuring
      assignment errors. This fixes the regression by not deserializing
      the class scope that's going to be reparsed, and using the positions
      of the scopes to tell whether the scope info matches the reparsed
      scope and can be used to fix up the allocation info.
      
      Original change's description:
      > [class] implement reparsing of class instance member initializers
      >
      > Previously, since the source code for the synthetic class instance
      > member initializer function was recorded as the span from the first
      > initializer to the last initializer, there was no way to reparse the
      > class and recompile the initializer function. It was working for
      > most use cases because the code for the initializer function was
      > generated eagarly and it was usually alive as long as the class was
      > alive, so the initializer wouldn't normally be lazily parsed. This
      > didn't work, however, when the class was snapshotted with
      > v8::SnapshotCreator::FunctionCodeHandling::kClear,
      > becuase then we needed to recompile the initializer when the class
      > was instantiated. This patch implements the reparsing so that
      > these classes can work with FunctionCodeHandling::kClear.
      >
      > This patch refactors ParserBase::ParseClassLiteral() so that we can
      > reuse it for both parsing the class body normally and reparsing it
      > to collect initializers. When reparsing the synthetic initializer
      > function, we rewind the scanner to the beginning of the class, and
      > parse the class body to collect the initializers. During the
      > reparsing, field initializers are parsed with the full parser while
      > methods of the class are pre-parsed.
      >
      > A few notable changes:
      >
      > - Extended the source range of the initializer function to cover the
      >   entire class so that we can rewind the scanner to parse the class
      >   body to collect initializers (previously, it starts from the first
      >   field initializer and ends at the last initializer). This resulted
      >   some expectation changes in the debugger tests, though the
      >   initializers remain debuggable.
      > - A temporary ClassScope is created during reparsing. After the class
      >   is reparsed, we use the information from the ScopeInfo to update
      >   the allocated indices of the variables in the ClassScope.
      >
      > Bug: v8:10704
      > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Cr-Commit-Position: refs/heads/main@{#78299}
      
      Bug: chromium:1278086, chromium:1278085, v8:10704
      Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#78745}
      0e07eb53
  5. 19 Jan, 2022 1 commit
  6. 09 Dec, 2021 1 commit
    • Joyee Cheung's avatar
      Revert "[class] implement reparsing of class instance member initializers" · f668e9f7
      Joyee Cheung authored
      This reverts commit 91f08378.
      
      Reason for revert: It's a fairly big change, and the clusterfuzz
      found some bugs. Will reland with the fix after M98 branch point.
      
      Original change's description:
      > [class] implement reparsing of class instance member initializers
      >
      > Previously, since the source code for the synthetic class instance
      > member initializer function was recorded as the span from the first
      > initializer to the last initializer, there was no way to reparse the
      > class and recompile the initializer function. It was working for
      > most use cases because the code for the initializer function was
      > generated eagarly and it was usually alive as long as the class was
      > alive, so the initializer wouldn't normally be lazily parsed. This
      > didn't work, however, when the class was snapshotted with
      > v8::SnapshotCreator::FunctionCodeHandling::kClear,
      > becuase then we needed to recompile the initializer when the class
      > was instantiated. This patch implements the reparsing so that
      > these classes can work with FunctionCodeHandling::kClear.
      >
      > This patch refactors ParserBase::ParseClassLiteral() so that we can
      > reuse it for both parsing the class body normally and reparsing it
      > to collect initializers. When reparsing the synthetic initializer
      > function, we rewind the scanner to the beginning of the class, and
      > parse the class body to collect the initializers. During the
      > reparsing, field initializers are parsed with the full parser while
      > methods of the class are pre-parsed.
      >
      > A few notable changes:
      >
      > - Extended the source range of the initializer function to cover the
      >   entire class so that we can rewind the scanner to parse the class
      >   body to collect initializers (previously, it starts from the first
      >   field initializer and ends at the last initializer). This resulted
      >   some expectation changes in the debugger tests, though the
      >   initializers remain debuggable.
      > - A temporary ClassScope is created during reparsing. After the class
      >   is reparsed, we use the information from the ScopeInfo to update
      >   the allocated indices of the variables in the ClassScope.
      >
      > Bug: v8:10704
      > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Cr-Commit-Position: refs/heads/main@{#78299}
      
      Bug: v8:10704
      Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
      Auto-Submit: Joyee Cheung <joyee@igalia.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78315}
      f668e9f7
  7. 08 Dec, 2021 2 commits
    • Leszek Swirski's avatar
      [compiler] Use SmallVector for Parser->BG thread use counts · ffdc50a9
      Leszek Swirski authored
      Change the off-thread parse to fill a SmallVector<UseCounterFeature, 8>
      on the BG compile task, rather than an int[kUseCounterFeatureCount]
      array. This allows us to keep the loop over use counts in the compile
      task finalization short by avoiding looping over unused counters.
      
      The value 8 was chosen as a "reasonable small number"; experimenting on
      our benchmarks shows a max of 3 use counts collected per compile (and
      at a vanishingly low percentage of all compiles).
      
      Passing around an explicit SmallVector<UseCounterFeature, 8> pointer,
      complete with size, is a bit ugly, but since it's used only in this one
      place (Parser -> BackgroundCompileTask) I can live with it to avoid
      further indirections. Typedeffing it is possible, but it's not clear
      where, since it's needed in both src/codegen/compiler.h and
      src/parsing/parser.h, and neither includes the other.
      
      Change-Id: Idb73e2f56fa9e8911ea29fb810d7562246f19d46
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318662Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78305}
      ffdc50a9
    • Joyee Cheung's avatar
      [class] implement reparsing of class instance member initializers · 91f08378
      Joyee Cheung authored
      Previously, since the source code for the synthetic class instance
      member initializer function was recorded as the span from the first
      initializer to the last initializer, there was no way to reparse the
      class and recompile the initializer function. It was working for
      most use cases because the code for the initializer function was
      generated eagarly and it was usually alive as long as the class was
      alive, so the initializer wouldn't normally be lazily parsed. This
      didn't work, however, when the class was snapshotted with
      v8::SnapshotCreator::FunctionCodeHandling::kClear,
      becuase then we needed to recompile the initializer when the class
      was instantiated. This patch implements the reparsing so that
      these classes can work with FunctionCodeHandling::kClear.
      
      This patch refactors ParserBase::ParseClassLiteral() so that we can
      reuse it for both parsing the class body normally and reparsing it
      to collect initializers. When reparsing the synthetic initializer
      function, we rewind the scanner to the beginning of the class, and
      parse the class body to collect the initializers. During the
      reparsing, field initializers are parsed with the full parser while
      methods of the class are pre-parsed.
      
      A few notable changes:
      
      - Extended the source range of the initializer function to cover the
        entire class so that we can rewind the scanner to parse the class
        body to collect initializers (previously, it starts from the first
        field initializer and ends at the last initializer). This resulted
        some expectation changes in the debugger tests, though the
        initializers remain debuggable.
      - A temporary ClassScope is created during reparsing. After the class
        is reparsed, we use the information from the ScopeInfo to update
        the allocated indices of the variables in the ClassScope.
      
      Bug: v8:10704
      Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#78299}
      91f08378
  8. 03 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Create ParseInfo on BG thread · a66c7a38
      Leszek Swirski authored
      Rather than creating a ParseInfo when creating a BackgroundCompileTask
      (and passing ownership across to the BG thread which deallocates it),
      create one when running it.
      
      This allows the ParseInfo Zone to be both allocated and deallocated on
      the same thread, which will improve its allocator friendliness.
      
      As a side-effect, we now use the on-heap PreparseData from the
      SharedFunctionInfo, rather than cloning the in-Zone PreparseData. This
      means that we don't have to copy the PreparseData across Zones, but we
      do need to Unpark the LocalHeap when accessing preparse data.
      
      Change-Id: I16d976c1ad54c1090180f2936f40a23a6dbb5904
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312483Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78228}
      a66c7a38
  9. 01 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Enqueue tasks for non-eager inner funcs · 5ab1ec1e
      Leszek Swirski authored
      Add suppose for compiling non-eager, non-top-level inner functions in
      parallel, using the compiler dispatcher. This behaviour can be enabled
      with --parallel-compile-tasks-for-lazy.
      
      There are a couple of consequences:
      
        * To support this we need support for off-thread ScopeInfo
          deserialization, so this adds that too.
        * The previous --parallel-compile-tasks flag is renamed to the more
          descriptive --parallel-compile-tasks-for-eager-toplevel.
        * Both parallel-compile-tasks flags are moved onto
          UnoptimizedCompileFlags so that they can be enabled/disabled on a
          per-compile basis (e.g. enabled for streaming, disabled for
          re-parsing).
        * asm.js compilations can now happen without an active Context (in
          the compiler dispatcher's idle finalization) so we can't get a
          ContextId for metric reporting; we'd need to somehow fix this if we
          wanted asm.js UKM but for now it's probably fine.
        * Took the opportunity to clean up some of the "can preparse" logic in
          the parser.
      
      Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78183}
      5ab1ec1e
  10. 12 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [parser] Pass LocalIsolate to ParseOnBackground · 8685bd0c
      Leszek Swirski authored
      Unify parse post-processing between main-thread and background-thread
      parsing, now that we have LocalIsolate and can Internalize on background
      threads.
      
      As part of this, simplify the LocalIsolate parking pattern to explicitly
      park during ParseOnBackground, rather than being implicitly parked when
      ParseOnBackground is called. This reduces the amound of scoping needed
      in the BackgroundCompileTask::Run method.
      
      Change-Id: Ifdb128b763129bda78bd1bae89dac1c62f872350
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277876
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77872}
      8685bd0c
  11. 04 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move to full SFI keying · 14097e62
      Leszek Swirski authored
      Remove the concept of JobId from LazyCompileDispatcher, and make SFIs
      the canonical id for these jobs.
      
      This has several consequences:
      
        * We no longer split enqueing a job and registering a SFI with that
          job. We did this previously because we could not allocate SFIs in
          the Parser -- now with LocalHeap we can, so we do.
        * We remove the separate Job vector, and make the SFI IdentityMap
          hold pointers to Jobs directly. This requires a small amount of
          extra care to deallocate Jobs when removing them from the map,
          but it means not having to allocate new global handles for jobs.
        * The SFI is passed into the BackgroundCompileTask instead of the
          script, so our task finalization doesn't need the SFI anymore.
        * We no longer need to iterate ParallelTasks after compiling (to
          register SFIs), so we can get rid of ParallelTasks entirely and
          access the dispatcher directly from the parser.
      
      There are a few drive-bys since we're touching this code:
      
        * Jobs are move to have a "state" variable rather than a collection
          of bools, for stricter DCHECKing.
        * There's no longer a set of "currently running" jobs, since this
          was only used to check if a job is running, we can instead inspect
          the job's state directly.
        * s/LazyCompilerDispatcher/LazyCompileDispatcher/g
      
      Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77712}
      14097e62
  12. 03 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      Reland "[off-thread] Allow off-thread top-level IIFE finalization" · 548c40ed
      Leszek Swirski authored
      This is a reland of 35a6eeec
      
      Reland fixes:
        * Add a SharedFunctionInfo::CopyFrom to encapsulate updating the SFI
          from the placeholder. This now includes copying scope_info (which
          wasn't included in the original CL and caused some of the issues)
        * Make sure that LocalHandleScope is initialised only inside of
          UnparkedScope (fixed TSAN issues)
        * Clean-up: Don't add `script_` to ParseInfo, but instead pass it
          separately to Parser. Eventually we'd ideally get rid of ParseInfo
          entirely (splitting it into input and output) so let's not add more
          fields to it. Reverts changing CreateScript to InitializeScript.
      
      Original change's description:
      > [off-thread] Allow off-thread top-level IIFE finalization
      >
      > Allow off-thread finalization for parallel compile tasks (i.e. for top-
      > level IIFEs).
      >
      > This allows us to merge the code paths in BackgroundCompileTask, and
      > re-enable the compiler dispatcher tests under the off-thread
      > finalization flag. Indeed, we can simplify further and get rid of that
      > flag entirely (it has been on-by-default for several releases now).
      >
      > Change-Id: I54f361997d651667fa813ec09790a6aab4d26774
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226780
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77615}
      
      Change-Id: If1a5b14900aa6753561e34e972a293be0be9a07d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256692
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77676}
      548c40ed
  13. 12 Oct, 2021 1 commit
  14. 11 Oct, 2021 1 commit
  15. 26 Aug, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Early errors 🤯 · a56874d3
      Jakob Gruber authored
      This CL implements early SyntaxErrors for regular expressions. Early
      errors are thrown when a malformed pattern is parsed, rather than when
      the code first runs.
      
      We do this by having the JS parser call into the regexp parser when
      a regexp pattern is found. Regexps are expected to be relatively
      rare, small, and cheap to parse - that's why we currently accept that
      the regexp parser does unnecessary work (e.g. creating the AST
      structures).
      
      If needed, we can optimize in the future. Ideas:
      
      - Split up the regexp parser to avoid useless work for syntax validation.
      - Preserve parser results to avoid reparsing later.
      
      Bug: v8:896
      Change-Id: I3d1ec18c980ba94439576ac3764138552418b85d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3106647
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76502}
      a56874d3
  16. 06 Jul, 2021 1 commit
  17. 18 Jun, 2021 1 commit
  18. 26 Apr, 2021 1 commit
  19. 23 Apr, 2021 1 commit
  20. 19 Mar, 2021 2 commits
  21. 15 Mar, 2021 1 commit
  22. 18 Feb, 2021 1 commit
  23. 09 Feb, 2021 1 commit
  24. 13 Jan, 2021 1 commit
  25. 26 Nov, 2020 1 commit
  26. 12 Nov, 2020 1 commit
    • Daniel Clark's avatar
      Sort import assertions by code point order of the keys · 73f8a710
      Daniel Clark authored
      Per https://tc39.es/proposal-import-assertions/#sec-assert-clause-to-assertions,
      import assertions should be sorted by the import assertion [[Key]]s,
      in order to prevent hosts from relying on a changing order of the
      assertions to determine behavior.
      
      Prior to this change, the assertions were being sorted by pointer. With
      this CL, the keys are sorted using a code point ordering so that the
      order of the assertions received by the host will be stable and
      non-surprising.
      
      This CL also switches the SourceTextModuleDescriptor's ModuleRequestMap,
      RegularExportMap, and RegularImportMap to use the code point order
      comparison rather than their former shortlex sort.  This change will not
      be externally visible, but it seems best to make these consistent.
      
      In order to avoid #including the fairly large ast-value-factory.h
      into ast/modules.h, I changed ImportAssertions into a separate class
      definition rather than keeping it as a typedef.  The alternative would
      be to define a common AstRawStringComparer in ast-value-factory.h and
      then #include ast-value-factory.h in both ast/modules.h and
      parsing/parser.h so that the ImportAssertions typedef would have a
      full, shared definition of the AstRawStringComparer type.
      
      Bug: v8:10958
      Change-Id: I29c9544aa0a4340c56e1ee631be6cabb2a2eb921
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2533038
      Commit-Queue: Dan Clark <daniec@microsoft.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71165}
      73f8a710
  27. 21 Oct, 2020 1 commit
  28. 19 Oct, 2020 1 commit
  29. 15 Oct, 2020 1 commit
  30. 25 Sep, 2020 1 commit
  31. 10 Aug, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [ast] Store correct source position on ThisExpression · 8a9e3f64
      Sathya Gunasekaran authored
      Previously, all ThisExpression's had kNoSourcePositions leading to
      incorrect error messages like this:
      
        ➜ d8 -e "function t() { for (const x of this) {} } t();"
        unnamed:1: TypeError: undefined is not a function
        function t() { for (const x of this) {} } t();
                  ^
        TypeError: undefined is not a function
            at t (unnamed:1:11)
            at unnamed:1:43
      
      
      This patch allows creation of a ThisExpression with a source position,
      leading to a better error message:
      
        ➜ d8  -e "function t() { for (const x of this) {} } t();"
        unnamed:1: TypeError: this is not iterable
        function t() { for (const x of this) {} } t();
                                       ^
        TypeError: this is not iterable
            at t (unnamed:1:32)
            at unnamed:1:43
      
      
      This patch does not remove the existing cached version of
      ThisExpression and instead creates a new one when required.
      
      Bug: v8:6513
      Change-Id: Idee4fe8946a9b821d06ff4a5e7eaefe54874ec59
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345226Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69300}
      8a9e3f64
  32. 13 Jul, 2020 1 commit
  33. 16 Jun, 2020 1 commit
  34. 10 Jun, 2020 1 commit
  35. 06 May, 2020 1 commit
    • Leszek Swirski's avatar
      [parser] Move Compiler::Analyze into Parser · 65d738d4
      Leszek Swirski authored
      Move rewriting, scope analysis, and internalization, to be unconditional
      operations done after parsing rather than a separate compile phase. This
      removes some of the complexity about rememberering when to call
      Compiler::Analyze, and makes these paths a bit more uniform.
      
      Also, forbid allocating any more AST strings after AstValueFactory
      internalization, by nulling out the Zone. Add an InternalizePartial
      method which doesn't null out the zone for those cases where we do want
      to be able to allocate after internalizing (e.g. internalization before
      scope analysis).
      
      Change-Id: Id444246d8362a1d169baf664fc37657d9576fd96
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182458Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67608}
      65d738d4
  36. 22 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      Reland^5 "[parser] Introduce UnoptimizedCompileFlags" · a3228bfc
      Leszek Swirski authored
      This is a reland of e1b93a4f
      which was a reland of 313d4844
      which was a reland of 0a59e0cb
      which was a reland of 146f5375
      which was a reland of d91679bf
      
      Give up on using C++ bitfields, go back to having base::BitField and
      getters/setters.
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      >
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      >
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      >
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,szuend@chromium.org
      
      Bug: v8:10314
      Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67309}
      a3228bfc
  37. 21 Apr, 2020 2 commits
    • Leszek Swirski's avatar
      Revert "Reland^4 "[parser] Introduce UnoptimizedCompileFlags"" · 33ea5e55
      Leszek Swirski authored
      This reverts commit e1b93a4f.
      
      Reason for revert: MSVC failing https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/13274
      
      Original change's description:
      > Reland^4 "[parser] Introduce UnoptimizedCompileFlags"
      > 
      > This is a reland of 313d4844
      > which was a reland of 0a59e0cb
      > which was a reland of 146f5375
      > which was a reland of d91679bf
      > 
      > Manually zero out flags with memset, since GCC appears not to initialize
      > the bitfield values to zero even with a default constructor.
      > 
      > Original change's description:
      > > [parser] Introduce UnoptimizedCompileFlags
      > >
      > > UnoptimizedCompileFlags defines the input flags shared between parse and
      > > compile (currently parse-only). It is set initially with some values, and
      > > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > > for the fields, but no setters).
      > >
      > > Since a few of the existing flags were output flags, ParseInfo now has a
      > > new output_flags field, which will eventually migrate to a ParseOutputs
      > > structure.
      > >
      > > Bug: v8:10314
      > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66782}
      > 
      > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
      > 
      > Bug: v8:10314
      > Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67271}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
      
      Change-Id: I0f41e847d4edae67e131cc6d0f782137ab73bac2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10314
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157377Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67275}
      33ea5e55
    • Leszek Swirski's avatar
      Reland^4 "[parser] Introduce UnoptimizedCompileFlags" · e1b93a4f
      Leszek Swirski authored
      This is a reland of 313d4844
      which was a reland of 0a59e0cb
      which was a reland of 146f5375
      which was a reland of d91679bf
      
      Manually zero out flags with memset, since GCC appears not to initialize
      the bitfield values to zero even with a default constructor.
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      >
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      >
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      >
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
      
      Bug: v8:10314
      Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67271}
      e1b93a4f