- 08 Jul, 2021 2 commits
-
-
Patrick Thier authored
This is a reland of 819c3ae2 Original change's description: > Reland "Reland "Improve error messages for property access on null/undefined"" > > This is a reland of 8b18c5e6 > > Original change's description: > > Reland "Improve error messages for property access on null/undefined" > > > > This is a reland of 24c626c1 > > > > Original change's description: > > > Improve error messages for property access on null/undefined > > > > > > Only print the property name when accessing null/undefined if we can > > > convert it to a string without causing side effects. > > > If we can't, omit the property name in the error message. > > > This should avoid confusion when the key is an object with toString(). > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > > Object]' anymore, which was misleading since the property accessed would > > > be 'a', but we can't evaluate the key without side effects. > > > > > > Bug: v8:11365 > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#75250} > > > > Bug: v8:11365 > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75571} > > Bug: v8:11365 > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219 > Auto-Submit: Patrick Thier <pthier@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75604} Bug: v8:11365 Change-Id: I002b537144f328ccbbdcd655e26e5dc87c49c6f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013935Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75645}
-
Leszek Swirski authored
This reverts commit 819c3ae2. Reason for revert: Sorry Patrick, still failing on some layout tests :( https://test-results.appspot.com/data/layout_results/mac-rel/726365/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html Original change's description: > Reland "Reland "Improve error messages for property access on null/undefined"" > > This is a reland of 8b18c5e6 > > Original change's description: > > Reland "Improve error messages for property access on null/undefined" > > > > This is a reland of 24c626c1 > > > > Original change's description: > > > Improve error messages for property access on null/undefined > > > > > > Only print the property name when accessing null/undefined if we can > > > convert it to a string without causing side effects. > > > If we can't, omit the property name in the error message. > > > This should avoid confusion when the key is an object with toString(). > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > > Object]' anymore, which was misleading since the property accessed would > > > be 'a', but we can't evaluate the key without side effects. > > > > > > Bug: v8:11365 > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#75250} > > > > Bug: v8:11365 > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75571} > > Bug: v8:11365 > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219 > Auto-Submit: Patrick Thier <pthier@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75604} Bug: v8:11365 Change-Id: I7d7c0f201288384c2aa38a51418b582a64213ae0 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013352 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75626}
-
- 07 Jul, 2021 1 commit
-
-
Patrick Thier authored
This is a reland of 8b18c5e6 Original change's description: > Reland "Improve error messages for property access on null/undefined" > > This is a reland of 24c626c1 > > Original change's description: > > Improve error messages for property access on null/undefined > > > > Only print the property name when accessing null/undefined if we can > > convert it to a string without causing side effects. > > If we can't, omit the property name in the error message. > > This should avoid confusion when the key is an object with toString(). > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > Object]' anymore, which was misleading since the property accessed would > > be 'a', but we can't evaluate the key without side effects. > > > > Bug: v8:11365 > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75250} > > Bug: v8:11365 > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75571} Bug: v8:11365 Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219 Auto-Submit: Patrick Thier <pthier@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75604}
-
- 06 Jul, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit 8b18c5e6. Reason for revert: Still failing: https://test-results.appspot.com/data/layout_results/V8_Blink_Linux/12469/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html Original change's description: > Reland "Improve error messages for property access on null/undefined" > > This is a reland of 24c626c1 > > Original change's description: > > Improve error messages for property access on null/undefined > > > > Only print the property name when accessing null/undefined if we can > > convert it to a string without causing side effects. > > If we can't, omit the property name in the error message. > > This should avoid confusion when the key is an object with toString(). > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > Object]' anymore, which was misleading since the property accessed would > > be 'a', but we can't evaluate the key without side effects. > > > > Bug: v8:11365 > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75250} > > Bug: v8:11365 > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75571} Bug: v8:11365 Change-Id: Ic4137f0d70fa9b10ca70fa921b98ea7e1499f11b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008217 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75577}
-
Patrick Thier authored
This is a reland of 24c626c1 Original change's description: > Improve error messages for property access on null/undefined > > Only print the property name when accessing null/undefined if we can > convert it to a string without causing side effects. > If we can't, omit the property name in the error message. > This should avoid confusion when the key is an object with toString(). > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > Object]' anymore, which was misleading since the property accessed would > be 'a', but we can't evaluate the key without side effects. > > Bug: v8:11365 > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75250} Bug: v8:11365 Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75571}
-
- 21 Jun, 2021 1 commit
-
-
Bill Budge authored
This reverts commit 24c626c1. Reason for revert: Blocks V8 roll into Chromium (changed error messages cause tests to fail): https://ci.chromium.org/p/chromium/builders/try/linux-rel/724109? Original change's description: > Improve error messages for property access on null/undefined > > Only print the property name when accessing null/undefined if we can > convert it to a string without causing side effects. > If we can't, omit the property name in the error message. > This should avoid confusion when the key is an object with toString(). > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > Object]' anymore, which was misleading since the property accessed would > be 'a', but we can't evaluate the key without side effects. > > Bug: v8:11365 > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75250} Bug: v8:11365 Change-Id: Ic63f34033254f55b3871041633d84ea48586a75d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2977374 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#75282}
-
- 18 Jun, 2021 2 commits
-
-
Patrick Thier authored
Only print the property name when accessing null/undefined if we can convert it to a string without causing side effects. If we can't, omit the property name in the error message. This should avoid confusion when the key is an object with toString(). E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object Object]' anymore, which was misleading since the property accessed would be 'a', but we can't evaluate the key without side effects. Bug: v8:11365 Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75250}
-
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}
-
- 09 Jun, 2021 1 commit
-
-
Dan Elphick authored
By moving this out of counters.h, counters.h no longer needs to depend on isolate.h. Change-Id: Ic5272e3b3a729c0a438124dc5cdc1835817f3341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949098 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75055}
-
- 12 Apr, 2021 1 commit
-
-
Camillo Bruni authored
Make runtime-call-stats a compile-time flag. Disabling RCS saves roughly 1MB binary size on 64bit systems and yields minor performance improvements. Bug: v8:11299 Change-Id: Ia1db75e330a665db5251b685c164b96857e38d2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2799766Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#73910}
-
- 08 Apr, 2021 1 commit
-
-
Victor Gomes authored
https://github.com/tc39/proposal-error-cause Bug: chromium:1192162 Change-Id: If6e2d1f105bb520104bb832ccbc7f660bb8115a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784681 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#73855}
-
- 11 Mar, 2021 3 commits
-
-
Clemens Backes authored
This is a reland of 80f5dfda. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
-
Clemens Backes authored
This reverts commit 80f5dfda. Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} Bug: v8:11238 Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866 Auto-Submit: Clemens Backes <clemensb@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#73346}
-
Clemens Backes authored
This is the biggest chunk, including - all of src/wasm, - torque file for wasm objects, - torque file for wasm builtins, - wasm builtins, - wasm runtime functions, - int64 lowering, - simd scala lowering, - WasmGraphBuilder (TF graph construction for wasm), - wasm frame types, - wasm interrupts, - the JSWasmCall opcode, - wasm backing store allocation. Those components are all recursively entangled, so I found no way to split this change up further. Some includes that were recursively included by wasm headers needed to be added explicitly now. backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc because it only tests wasm backing stores. This file is excluded from no-wasm builds then. R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org Bug: v8:11238 Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#73344}
-
- 16 Feb, 2021 1 commit
-
-
Sathya Gunasekaran authored
The current API returns a Handle<NativeContext> which can be optionally null and all the users of this API never actually checked for this null value. Previously, this wasn't a problem as all the possible JSObjects that were user visible would return a valid NativeContext but now there are wasm objects that don't have a valid constructor so don't have a NativeContext. Bug: v8:11451, chromium:1166077 Change-Id: I4fd5edf8f1a750e6f0abb931fd41358e5ae4dfcf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692695 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#72769}
-
- 12 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
Following up on https://crrev.com/c/2689185, this CL significantly simplifies the whole implementation of the stack trace capturing. Before this CL, capturing any stack trace (for the purpose of the API or Error.stack) would roughly work like this: 1. The CaptureStackTrace() function uses the StackFrameIterator to walk the system stack. For each native frame it uses the FrameSummary abstraction to get all (including potentially inlined) frames. For each of those it appends a record consisting of six elements to a FrameArray (this holds pointers to the actual closures and receivers). 2. Afterwards the FrameArray is shrinked to the required size, and a new FixedArray is allocated, and initialized with new StackTraceFrame objects where each holds a reference to the FrameArray, the index of the frame, and an initially uninitialized StackFrameInfo reference. This new FixedArray is then returned from CaptureStackTrace() and either stored on a message object or provided to the API as v8::StackTrace. The new approach removes a lot of the machinery in between and directly creates a FixedArray of StackFrameInfo objects in CaptureStackTrace(). These StackFrameInfo objects are directly exposed as v8::StackFrame on the public API, and they hold the six fields that were previously stored flat in the FrameArray. This not only avoids a lot of copying around of data and creation of temporary objects and handles, but most importantly unifies and simplifies the stack frame function inside StackFrameInfo, so you no longer need to wonder which function / object might be responsible for a certain API. There's still a lot of room for improvement. In particular we currently don't cache the source position for a given StackFrameInfo (or globally), but rather recompute it every time. This is still very fast, significantly faster than the previous approach. There are some notable (potentially user visible) changes: - The CallSite#GetPosition() method now consistently returns the Wasm module relative bytecode offset for all Wasm frames (previously it'd return the function relative bytecode offset for non-asm.js Wasm frames). - The column and line numbers returned from StackFrameInfo methods are consistently 1-based now, instead of sometimes being 0-based (Wasm) and sometimes being 1-based (JS and asm.js Wasm). The only potentially noticable difference is that for CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but that was wrong and useless anyways. - CallSite#GetThis() would sometimes return the_hole, another bug flushed out by this CL. The CL also contains some other not noteworthy drive-by-cleanups. Fixed: chromium:1057211 Bug: chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#72694}
-
- 09 Feb, 2021 1 commit
-
-
Clemens Backes authored
The interpreter frame is only used for testing now (see linked issue). This CL removes some remnants in messages.{h,cc}. R=bmeurer@chromium.org Bug: v8:10389 Change-Id: I369057ed02dbb68ba40ef9b4aa9a84799d3db528 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681944 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72581}
-
- 05 Feb, 2021 1 commit
-
-
Benedikt Meurer authored
In JSStackFrame::GetMethodName() we try to infer a useful method name to show for the closure to which the stack frame belongs. This is done by first considering the functions name, and checking if the receiver has a property with that name and if that property's value is the closure. In case the function doesn't have a name or the property's value is not the closure itself, we fall back to a reverse lookup of the closure within the object (and its prototypes). This CL speeds up this logic by attacking two problems: 1. The reverse lookup was performed by first using the KeyAccumulator to extract the names of all enumerable properties, and afterwards using the LookupIterator on each name, and testing the resulting property value against the closure. This is fairly slow and creates a lot of temporary objects and handles. We now look into the descriptor arrays or dictionary backing stores of the objects directly instead, which is easily 2-10x faster. 2. For the common case of `o.foo = function() { ... }` the parser already places an "inferred name" of `o.foo` onto the SharedFunctionInfo, which we can use as a hint to infer the name of the function instead of immediately falling back to the expensive reverse lookup. This repairs the regression reported in http://crbug.com/1069425 and recovers most of the slowdown reported in http://crbug.com/1077657 (there's still some overhead left from the async stack trace tracking). Fixed: chromium:1069425 Bug: chromium:1077657 Change-Id: I88d23ccad123906df70c5217e815493106e03ccf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#72545}
-
- 01 Dec, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: Iae76972afb7d1933b8eb57cf634053bb518eeb4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565080Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71509}
-
- 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}
-
- 23 Nov, 2020 3 commits
-
-
Bill Budge authored
This reverts commit 5557a63b. Reason for revert: Sheriff's mistake, failing test was previously flaking. Original change's description: > Revert "stack-trace-api: implement getEnclosingLine/Column" > > This reverts commit c48ae2d9. > > Reason for revert: Breaks a profiling test: > https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/30010 > > Original change's description: > > stack-trace-api: implement getEnclosingLine/Column > > > > Introduces getEnclosingColumn and getEnclosingLine on CallSite > > so that the position can be used to lookup the original symbol > > for function when source maps are used. > > > > BUG=v8:11157 > > > > Change-Id: I06c4c374d172d206579abb170c7b7a2bd3bb159f > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2547218 > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > > Commit-Queue: Benjamin Coe <bencoe@google.com> > > Cr-Commit-Position: refs/heads/master@{#71343} > > TBR=jkummerow@chromium.org,yangguo@chromium.org,bencoe@google.com > > Change-Id: Iab5c250c1c4fbdab86971f4a7e40abc8f87cf79c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:11157 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555384 > Reviewed-by: Bill Budge <bbudge@chromium.org> > Commit-Queue: Bill Budge <bbudge@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71345} TBR=bbudge@chromium.org,jkummerow@chromium.org,yangguo@chromium.org,bencoe@google.com # Not skipping CQ checks because this is a reland. Bug: v8:11157 Change-Id: I8dba19ceb29a24594469d2cf79626f741dc4cad3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555499Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#71348}
-
Bill Budge authored
This reverts commit c48ae2d9. Reason for revert: Breaks a profiling test: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/30010 Original change's description: > stack-trace-api: implement getEnclosingLine/Column > > Introduces getEnclosingColumn and getEnclosingLine on CallSite > so that the position can be used to lookup the original symbol > for function when source maps are used. > > BUG=v8:11157 > > Change-Id: I06c4c374d172d206579abb170c7b7a2bd3bb159f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2547218 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Benjamin Coe <bencoe@google.com> > Cr-Commit-Position: refs/heads/master@{#71343} TBR=jkummerow@chromium.org,yangguo@chromium.org,bencoe@google.com Change-Id: Iab5c250c1c4fbdab86971f4a7e40abc8f87cf79c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:11157 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555384Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#71345}
-
bcoe authored
Introduces getEnclosingColumn and getEnclosingLine on CallSite so that the position can be used to lookup the original symbol for function when source maps are used. BUG=v8:11157 Change-Id: I06c4c374d172d206579abb170c7b7a2bd3bb159f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2547218Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Benjamin Coe <bencoe@google.com> Cr-Commit-Position: refs/heads/master@{#71343}
-
- 24 Oct, 2020 1 commit
-
-
Camillo Bruni authored
This is a reland of eb6b4ce1 Skip test that serializes Error which references a Script. All errors created by ThrowAt store the current Script under the error_script_symbol. Original change's description: > [runtime] Use Isolate::ThrowAt with MessageLocation > > Fix various missing source positions when reporting parse and compile > errors. Namely this fixes missing source positions when having invalid > module imports. > > - Use Isolate::ThrowAt with valid MessageLocation objects > - Change public Isolate::Throw to no longer accept MessageLocation to > avoid misues > - Introduce private Isolate::ThrowInternal that accepts MessageLocation > > Bug: v8:6513 > Change-Id: I3ee633c9fff8c9d361bddb37f56e28a50c280ec1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467839 > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70623} Bug: v8:6513 Change-Id: Icba74f74178e28fbda0fd0c237eeb7bacbc33570 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487123Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#70741}
-
- 19 Oct, 2020 2 commits
-
-
Michael Achenbach authored
This reverts commit eb6b4ce1. Reason for revert: Might need rebaseline: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/7519 Original change's description: > [runtime] Use Isolate::ThrowAt with MessageLocation > > Fix various missing source positions when reporting parse and compile > errors. Namely this fixes missing source positions when having invalid > module imports. > > - Use Isolate::ThrowAt with valid MessageLocation objects > - Change public Isolate::Throw to no longer accept MessageLocation to > avoid misues > - Introduce private Isolate::ThrowInternal that accepts MessageLocation > > Bug: v8:6513 > Change-Id: I3ee633c9fff8c9d361bddb37f56e28a50c280ec1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467839 > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70623} TBR=marja@chromium.org,cbruni@chromium.org,ishell@chromium.org Change-Id: Ifa16ef8b6e5e411712fbad2e2a58fd700da12a69 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6513 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2485498Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#70631}
-
Camillo Bruni authored
Fix various missing source positions when reporting parse and compile errors. Namely this fixes missing source positions when having invalid module imports. - Use Isolate::ThrowAt with valid MessageLocation objects - Change public Isolate::Throw to no longer accept MessageLocation to avoid misues - Introduce private Isolate::ThrowInternal that accepts MessageLocation Bug: v8:6513 Change-Id: I3ee633c9fff8c9d361bddb37f56e28a50c280ec1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467839 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#70623}
-
- 30 Sep, 2020 1 commit
-
-
Jakob Kummerow authored
When building the error message for a TypeError when e.g. a non-callable is called, we should avoid running into the max string length. Printing many megabytes there isn't going to be useful anyway. Fixed: v8:10963 Change-Id: Ief89800f660bdd48585f84c3e3d4ece21b02b760 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2438068Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#70226}
-
- 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}
-
- 29 May, 2020 1 commit
-
-
Seth Brenith authored
This is a partial reland of https://crrev.com/c/v8/v8/+/2199640 . Change-Id: I528e43b8f6c5159148c16f1e2985efce2f1c2ec6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216307Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#68075}
-
- 26 May, 2020 1 commit
-
-
Seth Brenith authored
This reverts commit 4e5fabae. Reason for revert: performance regressions chromium:1085305, chromium:1084978 Original change's description: > [torque][cleanup] Use more precise field types in a few classes > > This change updates some Torque-defined classes to include more precise > field types where possible. It also updates those classes to use > @generateCppClass. One field was removed because it's unused > (PrototypeInfo::validity_cell), and two fields in StackFrameInfo > actually became less precise because they're based on Script::name, > which is an embedder-provided untyped Local<Value>. (Automatically > generated accessors pointed out this bug easily.) > > This change also includes a couple of minor fixes in Torque. > > Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67907} TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#67972}
-
- 19 May, 2020 1 commit
-
-
Seth Brenith authored
This change updates some Torque-defined classes to include more precise field types where possible. It also updates those classes to use @generateCppClass. One field was removed because it's unused (PrototypeInfo::validity_cell), and two fields in StackFrameInfo actually became less precise because they're based on Script::name, which is an embedder-provided untyped Local<Value>. (Automatically generated accessors pointed out this bug easily.) This change also includes a couple of minor fixes in Torque. Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67907}
-
- 13 May, 2020 1 commit
-
-
Marja Hölttä authored
We can't attach a meaningful stack trace to the AggregateError Promise.any rejects with, but we can augment the individual errors' stack traces with Promise.any and the index of the corresponding Promise in the input. Bug: v8:9808 Change-Id: I7ba754c9b043594decaac8b3a23be74f05c3dffd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198983 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#67778}
-
- 11 May, 2020 1 commit
-
-
Clemens Backes authored
Also, rename the WASM_COMPILED frame type to just WASM. R=jkummerow@chromium.org Bug: v8:10389 Change-Id: I71f16f41a69f8b0295ba34bd7d7fad71729546f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187613 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#67698}
-
- 06 May, 2020 1 commit
-
-
Clemens Backes authored
Interpreter entry compilation was removed in https://crrev.com/c/2172962. This CL removes the {WasmInterpreterEntryFrame} and the corresponding {WASM_INTERPRETER_ENTRY} code kind. Some follow-up cleanups are left as TODOs. R=jkummerow@chromium.org,bmeurer@chromium.org Bug: v8:10389 Change-Id: I1a43eba1ac1a751e05990c688088d99fc901231f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182456Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67607}
-
- 30 Apr, 2020 1 commit
-
-
Marja Hölttä authored
CL adopted from joshualitt@: https://chromium-review.googlesource.com/c/v8/v8/+/2002932 Link to explainer is here: https://github.com/tc39/proposal-promise-anyCo-authored-by: Joshua Litt <joshualitt@chromium.org> Bug: v8:9808 Change-Id: I6872020e857d4b131d5663f95fd58e6271ccb067 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2124834 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#67502}
-
- 24 Apr, 2020 1 commit
-
-
Camillo Bruni authored
Unify error handling for errors in CallWithSpread Bytecode and thus fix source location mismatches. Bug: v8:10378 Change-Id: If224cd34f1306492059dbedd8d2ca5c0feee5658 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162856Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#67365}
-
- 23 Apr, 2020 1 commit
-
-
Leszek Swirski authored
Move the persistent compilation state and Isolate inputs (such as the allocator, shared AST constants, hash seed, logger, etc.) which survives across both parse and compile, out of ParseInfo and into a new UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState for per-thread state such as stack limit and RCS. In particular, this new state survives the ParseInfo being destructed, which means it is available after off-thread finalization. This allows a followup to access the PendingCompilationErrorHandler after finalization and report errors on merge. Bug: v8:10314 Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67329}
-
- 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}
-