Acorn has a separate option to turn on compatibility for hashbang
comments. We need to turn on this flag for both our parser and
tokenizer.
Sadly, this wasn't enough to make the formatting work. What we discovered
is that comments can arrive out-of-order. In the case of hashbang
comments, we first receive the comment and then the token. However,
for all other comments, we first receive the token and then the comment.
To combat this reordering problem, we have to update our constructor
to only perform initializations when we don't have any comments at the start
(which is the situation for regular comments). Then when we do have
a hashbang comments, we bail out of shifting the comment away (and thus
would lose track of it) and let both `peekToken` and `nextToken` process
the comment.
R=bmeurer@chromium.org
Also-By: jacktfranklin@chromium.org
Fixed: 942422
Change-Id: Ic1971072b9c2d1e3ffeda7c3f9eede3b10f669fe
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2571126
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
In https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2102717
we are updating the Karma configuration to use the Ninja output for
all unittests. This CL includes all existing unittests in relevant
ts_library definitions and adds the corresponding (previously missed)
dependencies as ts_library as well.
Since most of these dependencies are actually not compiling with
the TypeScript compiler (the original intent of the CL linked above),
we are adding the @ts-nocheck annotation for now. Of course, we should
remove these annotations as soon as possible, but that is a bit more
work, as the tests involved are primarily UI driven.
R=jacktfranklin@chromium.org
# Windows presubmit breaks with large CLs
No-Presubmit: true
Bug: 1061125
Change-Id: Ic67dbbc805642eaa618340a67ea0975eaacffc24
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2162850
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
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>
The Chromium/Google style guides does not enforce curly braces for
single-line if-statements, but does strongly recommend doing so. Adding
braces will improve code readability, by visually separating code
blocks. This will also prevent issues where accidental additions are
pushed to the "else"-clause instead of in the if-block.
This CL also updates the presubmit `eslint` to run the fix with the
correct configuration. It will now fix all issues it can fix.
Change-Id: I4b616f21a99393f168dec743c0bcbdc7f5db04a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1821526
Commit-Queue: Tim Van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jeff Fisher <jeffish@microsoft.com>
Cr-Original-Commit-Position: refs/heads/master@{#701070}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7e0bdbe2d7f9fc2386bfaefda3cc29c66ccc18f9
Tim van der Lippe