- 12 May, 2022 1 commit
-
-
Jakob Kummerow authored
Hexadecimal/octal/binary BigInt property names should be converted to decimal, i.e. the following object literals should all be equivalent: var o = {0xF: 1}, p = {0xFn: 1}, q = {15: 1}, r = {15n: 1}. Test case by yangwenming@bytedance.com, uploaded at https://chromium-review.googlesource.com/c/v8/v8/+/3634937 Fixed: v8:10600 Change-Id: Ie1d8a16e95697cd31cbc0784843779c921ce91fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3642302Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#80490}
-
- 09 May, 2022 1 commit
-
-
Camillo Bruni authored
In preparation of renaming i::CodeEventDispatcher to i::Logger Bug: v8:12795, chromium:1316443 Change-Id: I28e129130852d41cf5e464e083bc27cff97a0fff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623543Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#80427}
-
- 03 Mar, 2022 1 commit
-
-
Michael Lippautz authored
The utility type is independent of V8 and useful for cppgc as well. Move to base/ to allow reusing. Change-Id: I9de9b4a87bb113fb4c2232d90253afb0f38faa68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497336Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#79346}
-
- 24 Jan, 2022 1 commit
-
-
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:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#78745}
-
- 19 Jan, 2022 1 commit
-
-
Shu-yu Guo authored
super.property accesses in heritage positions like `class C extends super.property` should resolve super in the current scope, not C's class scope. Bug: chromium:1282096 Change-Id: I7ef815bc02cfff35a2898ef9f39b133d1114046c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400150Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#78687}
-
- 09 Dec, 2021 1 commit
-
-
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:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78315}
-
- 08 Dec, 2021 2 commits
-
-
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:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78305}
-
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:
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}
-
- 03 Dec, 2021 1 commit
-
-
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:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78228}
-
- 01 Dec, 2021 1 commit
-
-
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:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/main@{#78183}
-
- 12 Nov, 2021 1 commit
-
-
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:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77872}
-
- 04 Nov, 2021 1 commit
-
-
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:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#77712}
-
- 03 Nov, 2021 1 commit
-
-
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:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77676}
-
- 12 Oct, 2021 1 commit
-
-
Leszek Swirski authored
We forgot to add statistic reporting for off-thread finalization -- this needs to be done during the main-thread fix-ups since it can call embedder callbacks. Change-Id: I3959a1512166cbdea028799c771f733a6c8a6163 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217198 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#77358}
-
- 11 Oct, 2021 1 commit
-
-
gengjiawen authored
MSVC seems to instantiate the Parser::PreParserIdentifierToAstRawString method despite it being unused. This CL adds an (unreachable) definition for it. Bug: v8:12266 Change-Id: I355ca82a9d6b7bc8cd16768a8df93e40f8bfc638 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199856Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77313}
-
- 26 Aug, 2021 1 commit
-
-
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:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#76502}
-
- 06 Jul, 2021 1 commit
-
-
Toon Verwaest authored
The preparser doesn't support extension parsing so always return false there, and move the field to the parser instead. Change-Id: Ie9ad0bd710858120467eb709ec92e59b38eaffba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009214Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75588}
-
- 18 Jun, 2021 1 commit
-
-
Dan Elphick authored
The adding of base:: was mostly prepared using git grep and sed: git grep -l <pattern> | grep -v base/vector.h | \ xargs sed -i 's/\b<pattern>\b/base::<pattern>/ with lots of manual clean-ups due to the resulting v8::internal::base::Vectors. #includes were fixed using: git grep -l "src/utils/vector.h" | \ axargs sed -i 's!src/utils/vector.h!src/base/vector.h!' Bug: v8:11879 Change-Id: I3e6d622987fee4478089c40539724c19735bd625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75243}
-
- 26 Apr, 2021 1 commit
-
-
Leszek Swirski authored
It's unfortunate that there is both a LocalIsolate template parameter, and an actual LocalIsolate class. Clean this up by renaming the template parameters to IsolateT Change-Id: Iecefc3eca5aeb7bbd21e78818b90f9e75cdff10f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846880 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#74173}
-
- 23 Apr, 2021 1 commit
-
-
Leszek Swirski authored
The ToString intrinsic isn't used anymore, since there is now a ToString bytecode, so we can remove it. Change-Id: I5ed121ae4d117660e1ee8a64a2b30e1fb054a886 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2848465 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#74151}
-
- 19 Mar, 2021 2 commits
-
-
Shu-yu Guo authored
Bug: v8:11573 Change-Id: Iab32d07443298bcd39c470ad92c5ce6db0a2b580 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2770603 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73550}
-
Shu-yu Guo authored
Calls with a spread expression in a non-final position get transformed to calls to Reflect.apply. This transformation is currently done in the parser, which does not compose well with other features (e.g. direct eval checking, optional chaining). Do this transform in the BytecodeGenerator instead. Bug: v8:11573, v8:11558, v8:5690 Change-Id: I56c90a2036fe5b43e0897c57766f666bf72bc3a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2765783 Auto-Submit: Shu-yu Guo <syg@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#73534}
-
- 15 Mar, 2021 1 commit
-
-
Clemens Backes authored
asm validation and translation to wasm is disabled in no-wasm builds, hence remove respective detection and marking of scopes and functions. R=verwaest@chromium.org Bug: v8:11238 Change-Id: I2ac8a84024fa37a0c5896a0f85ea4beea4d93137 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2757689Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73410}
-
- 18 Feb, 2021 1 commit
-
-
Shu-yu Guo authored
Stage 3 proposal: https://github.com/tc39/proposal-class-static-block Bug: v8:11375 Change-Id: I579adab4679cce0190b9d8bd814a7cd297ebfa15 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699449Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#72847}
-
- 09 Feb, 2021 1 commit
-
-
Shu-yu Guo authored
Implements https://github.com/tc39/ecma262/issues/2034 Currently the token sequence `for (async of` is ambiguous. It can be the prefix for either `(async of => {};;);` or `for (async of foo);`. This CL disallows the token sequence. Note that `for await (async of` is still allowed, since there is no C-style `for await (;;)`, and thus no ambiguity. Bug: v8:11412 Change-Id: I3fede83a69420996baa2bc8b6c1cff000535d990 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683221 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72607}
-
- 13 Jan, 2021 1 commit
-
-
bcoe authored
Implement coverage tracking for optional chains. Bug: v8:10060 Change-Id: I4f29eda64b6d859939f5f58f4fabead649905795 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2573013Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Gus Caplan <snek@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benjamin Coe <bencoe@google.com> Cr-Commit-Position: refs/heads/master@{#72075}
-
- 26 Nov, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Scopes in V8 are used to guarantee one or more properties during its lifetimes. If a scope is not named e.g MyClassScope(args) instead of MyClassScope scope(args) it will get created and automatically destroyed and therefore, being useless as a scope. This CL would produce a compiling warning when that happens to ward off this developer error. Follow-up to ccrev.com/2552415 in which it was introduced and implemented for Guard classes. Change-Id: Ifa0fb89cc3d9bdcdee0fd8150a2618af5ef45cbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555001 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71425}
-
- 12 Nov, 2020 1 commit
-
-
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:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#71165}
-
- 21 Oct, 2020 1 commit
-
-
Shu-yu Guo authored
Implements https://github.com/tc39/ecma262/pull/2154, which allows module export names to be string literals. Semantics highlights: - It is a SyntaxError for string literal export names to have unpaired UTF16 surrogates. - It is a SyntaxError for string literal export names to be used as the local name without being followed by a 'from' clause. For example, `export { "foo" }` and `export { "foo" as "bar" }` are errors, but `export { "foo" } from "./module.js"` is allowed. The remaining failing test262 test is wrong: https://github.com/tc39/test262/issues/2866 Bug: v8:10964 Change-Id: Ib3e06e1ee6b3f1b60ed7f24e21902e17ddfc0351 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482335 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#70692}
-
- 19 Oct, 2020 1 commit
-
-
Daniel Clark authored
Parse the AssertEntries in an import assertion clause, storing them in a map. Plumb them through the parser to the appropriate SourceTextModuleDescriptor methods. The next change will plumb them into the SourceTextModuleDescriptor's ModuleRequestMap and through to SourceTextModuleInfo::New. Bug: v8:10958 Change-Id: I19c31090520f14f94d014e760f5fe372bf773fc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2482326Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70622}
-
- 15 Oct, 2020 1 commit
-
-
Daniel Clark authored
This is the first change in the process of implementing import assertions per https://tc39.es/proposal-import-assertions/. This CR adds support for the empty form of the AssertClause. Also added is a --harmony-import-assertions flag to enable/disable import assertions. For now, the feature is off by default. The next change will enable the parser to handle a non-empty list of AssertEntries. Bug: v8:10958 Change-Id: I0832d89effc27225aa4430605a51690461daf7ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2468623Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70545}
-
- 25 Sep, 2020 1 commit
-
-
Bill Budge authored
Bug: v8:10933 Change-Id: I4db540cf47ce5cfa25757d776a2bf988ce3ed554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432072Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#70147}
-
- 10 Aug, 2020 1 commit
-
-
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:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#69300}
-
- 13 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... by migrating old-style code MyObject* obj = new (zone) MyObject(...) to the new style MyObject* obj = zone->New<MyObject>(...) Bug: v8:10689 Change-Id: I08e513911a6b4e5d564cab42720a197d1244dd2e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292238Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68819}
-
- 16 Jun, 2020 1 commit
-
-
Huáng Jùnliàng authored
Bug: v8:10564 Change-Id: Ibeaa43d9db087d02d8f4d3688fc1f6da41691a60 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216931Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#68373}
-
- 10 Jun, 2020 1 commit
-
-
Leszek Swirski authored
Remove error reporting from parsing::Parse*, since in most cases we didn't actually want them (clear errors afterward), and there was an issue where Compiler::Compile would try to report errors already reported in ParseAny, which ended up triggering unreachable code. As a drive-by, move some one-off parse exception handling in test-parsing into a CHECKED_PARSE_PROGRAM macro which replaces all the "necessarily positive" calls to parsing::ParseProgram. Bug: chromium:1091656 Change-Id: I4d463ec363312aea36ab92f1322cf66a416b9888 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237134Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#68281}
-
- 06 May, 2020 1 commit
-
-
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:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67608}
-
- 22 Apr, 2020 1 commit
-
-
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:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67309}
-
- 21 Apr, 2020 2 commits
-
-
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:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67275}
-
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:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67271}
-