The script previously assumed it would always be run from within the
chromium/src/third_party/devtools-frontend/src folder. It would fail
when run from the standalone repository at devtools/devtools-frontend.
This patch makes it work even in that case, as long as the `devtools`
directory in `devtools/devtools-frontend` lives on the same level as
the `chromium` repository.
Change-Id: I3cf81c8144fd3f03389a4ec395b8ec3acdbb8e55
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1939798
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@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>
TL;DR: When retrieving the file content with localization scripts,
normalize the line ending to LF.
Issue:
When a grdp file containing multi-line strings has CRLF line ending,
the parser doesn't work because the IDS hash is calculated based on the
content of the <message> tag, which expects LF line ending. The multi-
line string ends up having a different expected hash, and the parser
complains about it.
Repro:
Change line ending of front_end/coverage/coverage_strings.grdp to CRLF.
Fix:
Normalize line ending to LF when retrieving the file content.
Change-Id: If3a33978724a4bf9635738c67ada211e5e996e30
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1895994
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Mandy Chen <mandy.chen@microsoft.com>
Any module that is not autostart and has `modules` specified in its `module.json`
will now have its entrypoint dynamically imported. Update the release build script
to output the `modules` array as well so that the Runtime can load it.
Add additional entrypoints to `platform` and `dom_extension` to be consistent
with the naming patterns of all other modules
Bug:1006759
Change-Id: If6d10a13a62354079e3f8ee49bee4ecdcffa6758
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1893085
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