This changes the Common.Worker to create Workers that use the module
scope rather than the global scope. It allows us to use es-imports,
which consequently allows us to remove the bundling during the build
step. This should hopefully improve the Ninja non-determinism that we
were facing when making changes to files that are used in the various
workers.
Bug: 1006759
Change-Id: I7ac209817b1576d2accd790f1bf7ef6a658f5605
Fixed: 1013129
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1981615
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
check_gn will now properly check the contents of all_devtools_modules and copied_devtools_modules in the BUILD.gn.
We don't ship the wasm_source_map/types.js, as it only includes information for Closure.
Therefore, remove this file from the `modules` array and append it in Closure instead.
Fixed: 1033882
Change-Id: I3361096941869d39ce3b717327c4001d146a5286
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1969473
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This also makes cm_modes/ non-remote and uses proper dynamic imports to
load the code (rather than an `eval`). This increases the binary size by
104 KB from 11756K to 11860K which is an increase of 0.8%.
The stylus cm_mode has been removed. This mode was the largest mode
(30KB), seems unmaintained [1] and this syntax is likely rarely used (if
at all). It is unclear how often the other modes are installed and used.
Additionally, I discovered a promise race in the plugin installation. In
the full application this is not noticeable, as by default all code
mirror modes are lazily loaded (verified they still work with Markdown,
Java file and the regular js/cc files). However, in the test it was not
properly awaiting the plugin loading.
Perform the async-await plumbing to make sure the promise is resolved
before the test continues execution.
roll CodeMirror
[1]: https://github.com/codemirror/CodeMirror/commits/master/mode/stylus
Bug:1006759,1011466
Change-Id: If4d81d01318e08a63faaffee8b0cc9ab5954d4c6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1928924
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
cm_web_modes/ was used both in a worker and in the normal browser
context. However, both formatter_worker/ and text_editor/ included the
relevant files in their scripts array.
The fix is to make cm_web_modes a proper module and import either the
browser (_cm.js) variant or the worker (_headless.js) variant.
Bug: 1006759
Change-Id: I85c6f67102d8ffd94e073850b1ac7adcb289b1b2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1934218
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This reverts commit 402078e2f9.
Reason for revert: run_localization_check.py breaks the PRESUBMIT for any CLs which contain json files, i.e. module.json.
Original change's description:
> Adding run_localization_check.py
>
> It will run the two localization verifications:
> - It will tell if the resource files are formatted in the correct way
> - It ill tell if any localizable resource in the code is present with the
> appropiate attributes in the resource files.
>
> This two verifications already run as part of the presubmit verifications,
> I did some refactoring to allow them to be run from an external script.
>
> Change-Id: I340e5dcfdeef7331a757adf27cef94e22302cf10
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1894913
> Reviewed-by: Lorne Mitchell <lomitch@microsoft.com>
> Commit-Queue: Vidal Diazleal <vidorteg@microsoft.com>
TBR=lomitch@microsoft.com,vidorteg@microsoft.com
Change-Id: I0f2dfa1e071a0302414cf38ccbdf86ca772b3ec1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1926496
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
It will run the two localization verifications:
- It will tell if the resource files are formatted in the correct way
- It ill tell if any localizable resource in the code is present with the
appropiate attributes in the resource files.
This two verifications already run as part of the presubmit verifications,
I did some refactoring to allow them to be run from an external script.
Change-Id: I340e5dcfdeef7331a757adf27cef94e22302cf10
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1894913
Reviewed-by: Lorne Mitchell <lomitch@microsoft.com>
Commit-Queue: Vidal Diazleal <vidorteg@microsoft.com>
Since workers do not support modules [1], it is not possible to
currently import any ESM DevTools module. To be able to migrate
text_utils/ to ESM, we would need to duplicate a large portion of
text_utils/, which would be unmaintainable.
We already had the same situation when we migrated platform/ to ESM and
decided to copy the relevant functions, but this time around that is no
longer an option.
Thus, the 2 workers (heap_snapshot_worker and formatter_worker) are now
being bundled on build time. This means that in a release build, the
respective entrypoints are bundled and inserted in the output.
To bundle, we use `rollup`, which is a bundler only concerned with
rolling up ES modules. All other functionality of rollup (such as
tree-shaking) is unused. We can revisit later if we need a bundler for
the rest of devtools, but since we are in active migration to ESM that
is infeasible at this point in time.
As part of this CL, the following folders are migrated to ESM:
- cm_headless/
- formatter_worker/
- heap_snapshot_model/
- heap_snapshot_worker/
- text_utils/
Since text_utils is also an autostart module for the shell, this is the
only module that is imported from root.js.
Some of these modules also include files that are annotated with
skip_compilation and thus run with dummy files during Closure
compilation.
Note that, because of the usages of import-statements in the workers
and the blocking bug [1], the workers are generated even when Chromium
is built with `debug_devtools=true`.
Since heap_snapshot_model/ also used in the profiler, we have to eagerly
load this module in root.js. Once all other dependencies of the profiler
have been migrated to ESM, we can remove this import-statement.
[1]: crbug.com/680046
Bug:1013129,1006759
Change-Id: I4c03c7b8a1f351ae9693cbcd922412083dd34bba
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1883707
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This adds native location resolver, written in Rust and compiled to
WebAssembly, that can parse DWARF information from other given
WebAssembly modules and resolve addresses <-> source location mappings
in both directions.
From V8 side, this depends on recently added Debugger.getWasmBytecode
command and on a special "wasm://dwarf" source map URL reported for Wasm
modules that contain DWARF information.
On the JavaScript side, this uses autogenerated JavaScript bindings by
wasm-bindgen to an internal context which contains all parsed data and
lazily creates SDK.SourceMapEntry when requested. These bindings are
further wrapped into a public class that implements SDK.SourceMap
interface.
---
Always auto-step over Wasm DWARF
Wasm doesn't have any other source when DWARF is used for source
mapping, so it will step into an empty source pane.
This is not very useful, so let's always auto-step to the next resolved
location.
There are talks about stabilising auto-stepping for JS source maps as
well, but for now limiting to just the new functionality should be
safer.
Change-Id: I6e981dcd33a03a5db2f2b1e39a93372c5ba09b97
Bug: 1016772
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1872581
Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Tim van der Lippe