- 13 May, 2022 1 commit
-
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 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}
-
- 10 Dec, 2021 1 commit
-
-
Leszek Swirski authored
This allows us to reuse AstValueFactory's string table across multiple parsers, while still releasing memory after each individual parse. This is mild overkill for all the single parses that don't reuse AstValueFactories, but there at least the AstRawStrings now end up grouped together in memory, so that might have mild cache benefits. Change-Id: I0b378760b601fa4ec6559a0dca5d7ed6f895e992 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322764Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78338}
-
- 08 Dec, 2021 1 commit
-
-
Leszek Swirski authored
Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo, which stores a couple of pointers and most importantly the Zone and AstValueFactory of the parse. This allows the Zone and AstValueFactory to be reused across multiple parses, rather than re-initialising per-Parse. With this, we can amend the LazyCompileDispatcher to initialise one LocalIsolate, Zone and AstValueFactory per background thread loop, rather than one per compile task, which allows us to reduce per-task costs and re-use the AstValueFactory's string table and previous String internalizations. Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78289}
-
- 30 Nov, 2021 1 commit
-
-
Camillo Bruni authored
- V8::Deprecate ShutdownPlatform in favor of V8::DisposePlatform - Rename i::V8::TearDown to i::V8::Dispose - Clean up i::V8::Initialize - Remove needless V8::Initialize() calls in cctests - Remove CcTest::DisableAutomaticDispose() - Add checks to Isolate::Allocate and Isolate::Dispose that there is and active platform Change-Id: Iac84f9ade9d1781e9e8b8c88ea8fe74013f51c4a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306482 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78162}
-
- 08 Nov, 2021 1 commit
-
-
Ng Zhi An authored
Bug: v8:12244,v8:12245 Change-Id: Ic84020ea7e54c50dc8f773eb655078582bb33fa7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264361Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77771}
-
- 24 Aug, 2021 1 commit
-
-
Dan Elphick authored
This is a reland of d1b27019 Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
-
- 23 Aug, 2021 2 commits
-
-
Dan Elphick authored
This reverts commit d1b27019. Reason for revert: Broke vtune build, tsan build and possibly others Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Bug: v8:11965 Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#76428}
-
Dan Elphick authored
This moves every single class/function out of include/v8.h into a separate header in include/, which v8.h then includes so that externally nothing appears to have changed. Every include of v8.h from inside v8 has been changed to a more fine-grained include. Previously inline functions defined at the bottom of v8.h would call private non-inline functions in the V8 class. Since that class is now in v8-initialization.h and is rarely included (as that would create dependency cycles), this is not possible and so those methods have been moved out of the V8 class into the namespace v8::api_internal. None of the previous files in include/ now #include v8.h, which means if embedders were relying on this transitive dependency then it will give compile failures. v8-inspector.h does depend on v8-scripts.h for the time being to ensure that Chrome continue to compile but that change will be reverted once those transitive #includes in chrome are changed to include it directly. Full design: https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing Bug: v8:11965 Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76424}
-
- 01 Jul, 2021 1 commit
-
-
Toon Verwaest authored
Splits FLAG_lazy into - FLAG_lazy for main-thread compiled scripts/modules - FLAG_lazy_streaming for streamed scripts - FLAG_lazy_eval for eval This allows us to evaluate the impact of non-lazy compilation for streamed scripts. Change-Id: I8a362ea184e0afd3aa7cdb11a7eab5b7497a4691 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999090Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75518}
-
- 22 Jun, 2021 1 commit
-
-
Dan Elphick authored
Moves VSNPrintf, SNPrintf and StrNCpy out of utils/utils.h into base/strings.h. Bug: v8:11879 Change-Id: I0e165cb27c42f89c9acd1c6378514b40a90cd18d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972732 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75308}
-
- 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}
-
- 04 May, 2021 1 commit
-
-
Huáng Jùnliàng authored
Bug: v8:11722 Change-Id: I34569071d74f0fe68b30cf3a596ea944440f1fec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2864703Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74361}
-
- 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}
-
- 11 Mar, 2021 1 commit
-
-
Shu-yu Guo authored
Removes --harmony-string-replaceall (shipped since 8.5) --harmony-logical-assignment (shipped since 8.5) --harmony-atomics-waitasync (shipped since 8.7) Bug: v8:9801,v8:10372,v8:10239 Change-Id: Ifb8db93948a067e75da5e581603acb916b91342a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2747201 Commit-Queue: Shu-yu Guo <syg@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#73356}
-
- 29 Jan, 2021 1 commit
-
-
Marja Hölttä authored
Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
-
- 28 Jan, 2021 1 commit
-
-
Marja Hölttä authored
This reverts commit f6450b97. Reason for revert: ClusterFuzz bugs Original change's description: > Reland [super] Store home object in Context instead of JSFunction > > 1) Computed property keys (esp functions in them) shouldn't be inside > the object literal scope. > > 2) I was using an imprecise "maybe uses super" and storing it to > preparse data. This won't fly, since it pollutes sister scopes and > leads to confusion wrt whether an object literal needs a home object > or not. Made it precise (mostly cancelling changes in the original CL). > > 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for > this_function (which made it used) -> inconsistent scopes between > parsing and preparsing. > > 4) MultipleEntryBlockContextScope was messing up the accumulator > > Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 > > This saves memory (the home object doesn't need to be stored for each > method, but only once per class) and hopefully makes the home object > a constant in the optimized code. > > Detailed documentation of the changes: > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing > > Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 > Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Marja Hölttä <marja@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72169} TBR=marja@chromium.org,leszeks@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72391}
-
- 19 Jan, 2021 2 commits
-
-
Marja Hölttä authored
1) Computed property keys (esp functions in them) shouldn't be inside the object literal scope. 2) I was using an imprecise "maybe uses super" and storing it to preparse data. This won't fly, since it pollutes sister scopes and leads to confusion wrt whether an object literal needs a home object or not. Made it precise (mostly cancelling changes in the original CL). 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for this_function (which made it used) -> inconsistent scopes between parsing and preparsing. 4) MultipleEntryBlockContextScope was messing up the accumulator Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72169}
-
Maya Lekova authored
This reverts commit 4d5b878b. Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263 Original change's description: > [super] Store home object in Context instead of JSFunction > > This saves memory (the home object doesn't need to be stored for each > method, but only once per class) and hopefully makes the home object > a constant in the optimized code. > > Detailed documentation of the changes: > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing > > Bug: v8:9237 > Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 > Commit-Queue: Marja Hölttä <marja@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72137} TBR=marja@chromium.org,leszeks@chromium.org Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#72142}
-
- 18 Jan, 2021 1 commit
-
-
Marja Hölttä authored
This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72137}
-
- 07 Jan, 2021 2 commits
-
-
Daniel Clark authored
There's a bit more work to do to add support for import assertions for dynamic import(). This is the first of a series of changes to do that. This adds parser support for the form of import() that takes import assertions per https://tc39.es/proposal-import-assertions/#prod-ImportCall A future change will pass the assertions expression along to Runtime_DynamicImportCall where the assertions will be unpacked and filtered per Isolate::supported_import_assertions_. Bug: v8:10958 Change-Id: Ib1c80d15ac44923d97c5fdfcc4bd732cb9245cf9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612038Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71960}
-
Dan Clark authored
When --harmony-dynamic-import was removed in https://chromium-review.googlesource.com/c/v8/v8/+/2509942 it looks like we were left with some redundant invocations of RunParserSyncTest/RunModuleParserSyncTest in ImportExpressionErrors. This removes them. Change-Id: I2fb68c7e21bc4e039ab77396cdca7ca0d18eca95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613370Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71956}
-
- 20 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
- 12 Nov, 2020 2 commits
-
-
Shu-yu Guo authored
It's shipped since M84. Bug: v8:8330 Change-Id: Ia643948c0de83fc9a8faf7307b7fd86a1e117dc1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2511034 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#71166}
-
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}
-
- 11 Nov, 2020 1 commit
-
-
Daniel Clark authored
Code review follow-ups from: Plumb import assertions through SourceTextModuleDescriptor's ModuleRequestMap Address a few bits of code review feedback that came in after landing https://chromium-review.googlesource.com/c/v8/v8/+/2493060: - Add ModuleRequest:kAssertionEntrySize and use in place of a numeric literal. - Get rid of ModuleRequestLocation and separate module_request_positions FixedArray, and merge these into AstModuleRequest and v8::internal::ModuleRequest. Change-Id: If6d628d29bfa6fbd9933c6cdaa706623128ccc5d Bug: v8:10958 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2530478Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71125}
-
- 10 Nov, 2020 1 commit
-
-
Daniel Clark authored
This change plumbs import assertions from SourceTextModuleDescriptor's ModuleRequestMap into SourceTextModuleInfo via a new ModuleRequest type, where previously there had been only the specifier. SourceTextModuleDescriptor::module_map now deduplicates module requests using the specifier and the import assertions. Continuing to use the specifier alone would cause a loss of information in the event that a module imports from the same specifier multiple times using different sets of assertions. Failing to deduplicate at all would result in multiple requests for statements like `import {a,b,c} from "foo.js"`, which would be a potential performance issue. See design doc at https://docs.google.com/document/d/1yuXgNHSbTAPubT1Mg0JXp5uTrfirkvO1g5cHHCe-LmY for more detail on this decision. v8::internal::ModuleRequest holds the assertions as an array of the form [key1, value1, position1, key2, value2, assertion2, ...]. However the parser still needs to use a map, since duplicate assertion keys need to be detected at parse time. A follow-up change will ensure that assertions are sorted using a proper lexicographic sort. Bug: v8:10958 Change-Id: Iff13fb9a37d58fc1622cd3cce78925ad2b7a14bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493060 Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#71066}
-
- 03 Nov, 2020 4 commits
-
-
Shu-yu Guo authored
It's shipped since M72. Bug: v8:8101 Change-Id: I80856b9e1acfb6e434f20b6174e864f8c4e2896a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509945 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#70955}
-
Shu-yu Guo authored
It's shipped since M64. Bug: v8:6693 Change-Id: Ifc547c0036dd7e5f7bab9bcb169abee0157f73b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509943 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#70954}
-
Shu-yu Guo authored
It's shipped since M63. Bug: v8:5785 Change-Id: Iaa591890edc560bc58b7a6b18ad5787d747f1ba4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509942Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#70953}
-
Sathya Gunasekaran authored
This reverts commit 8156dd85. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20ASAN/15800/overview Original change's description: > GetCurrentStackPosition() -> base::Stack::GetCurrentStackPosition() > > Remove the duplicate utility function and use the base::Stack > equivalent instead which provides more stack utilitiy functionality. > > Change-Id: Ia7a79f2530b64ceb6e2ce33445c876980b4b2a3d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509595 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70930} TBR=mlippautz@chromium.org,clemensb@chromium.org,verwaest@chromium.org Change-Id: Id18949a3c82171e74370e729cd303607d46c8805 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2515431Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#70940}
-
- 02 Nov, 2020 1 commit
-
-
Michael Lippautz authored
Remove the duplicate utility function and use the base::Stack equivalent instead which provides more stack utilitiy functionality. Change-Id: Ia7a79f2530b64ceb6e2ce33445c876980b4b2a3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509595Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#70930}
-
- 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}
-
- 10 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: I79fc4f9793a0c7a3bd38230ca4e23d33344fc1b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288863Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68792}
-
- 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}
-
- 03 Jun, 2020 1 commit
-
-
Shu-yu Guo authored
This is a reland of c342ba82 Original change's description: > Set .name of anonymous functions on the RHS of logical assignment. > > https://github.com/tc39/proposal-logical-assignment/pull/24 reached > consensus in June TC39. > > Drive-by refactoring of testing for logical assignment ops using > IsInRange. > > Bug: v8:10579 > Change-Id: I5a203ba552a905cd28f75c5d223998431a1966ce > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2225809 > Reviewed-by: Marja Hölttä <marja@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68101} Bug: v8:10579 Change-Id: I321cf0e29515a146844abc05250e9b50ad651caf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2227255 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#68161}
-
- 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}
-
- 23 Apr, 2020 1 commit
-
-
Gus Caplan authored
https://tc39.es/proposal-logical-assignment/ Bug: v8:10372 Change-Id: I538d54af6b4b24d450d1398c74f76dd57fdb0147 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2158119Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#67330}
-