Previously, `attachFinally` took advantage of
`Reachability.rebaseForward` to compute reachability after a
`try/finally` statement. This was overkill, since
`Reachability.rebaseForward` contains special logic to account for
widely diverging reachability stacks, whereas `attachFinally` always
deals with reachability stacks that have an immediate common parent.
This change adds an assertion to verify that the reachability stacks
always have an immediate common ancestor, and replaces the call to
`Reachability.rebaseForward` with the equivalent direct logic.
Making this change will simplify the process of writing a spec for
flow analysis.
Change-Id: Icd7d3ebc150d1836932efe3891b3ea1077134351
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437300
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The reports the declaration conflicts through the _Declaration objects,
which streamlines the code and helps providing more targeted messages.
Change-Id: I013c9974de87c5a1c541ba6aa5d78a1ba63e1074
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437241
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Before an assist call on a file with non-windows lineendings would first
search through the entire file for Windows line endings, then search for
the non-Windows line endings. As such Windows line endings was faster.
This CL changes the semantics slightly from "Windows line endings if
any Windows line endings exist" to "whatever line endings are first
used" which should be good.
It speeds up assist calls with non-Windows line endings:
Statistics on 5 runs each:
```
Windows / 2000: No change.
Windows / 4000: No change.
Windows / 8000: No change.
Unix / 2000: 1000 assist calls: -46.9900% +/- 6.1715% (-0.88 +/- 0.12) (1.86 -> 0.99)
Unix / 4000: 1000 assist calls: -59.1561% +/- 6.3982% (-1.79 +/- 0.19) (3.03 -> 1.24)
Unix / 8000: 1000 assist calls: -63.8429% +/- 4.3083% (-3.68 +/- 0.25)(5.76 -> 2.08)
```
Change-Id: I61278ed4ad31b891e87951da0a6162fe37376888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437224
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The two pieces of information we're tracking are
- the number of libraries in each library cycle
- the number of lines of code in each library cycle
The data is reported in terms of percentage.
This doesn't give us any way to correlate the two values. Knowing that
there is a library cycle with M libraries and a cycle with N lines of
code, doesn't tell us whether it's the same library cycle in both cases.
Still, I think it will help us understand the nature of the code that
we need to be able to analyze quickly.
Change-Id: I36a8bf11c4c6fdced6c524225be7a633062351ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437126
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
By default the integration tests spawn the server using the snapshot from the active SDK. If you forget to recompile the SDK when running the integration tests, you may get inaccurate results.
One option is to set the `TEST_SERVER_SNAPSHOT` env variable to `"false"` which will run the tests from source, however using the "Run All Tests" command in VS Code will result in a lot of timeouts because tests run concurrently and each one will cause a compilation.
This change instead creates a new VS Code task that will compile the server to a temporary file in `.dart_tool`, and creates a launch configuration that triggers this task (via `preLaunchTask`) when running integration tests. This supports both running all tests (with the "Run All Tests" command) or running individual integration test files, with just a single up-front compilation.
Change-Id: I0970ffb76240abd54ff2c8a9c9be4bab40693691
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436341
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
The diff makes this change look bigger than it is.
Here's how the code worked before: `compute()` called `_addFromProducers()`. `_addFromProducers()` had a local function, also
called `compute()`, which is called per CorrectionProducer. The local
`compute()` function would unconditionally create a ChangeBuilder and
call each CorrectionProducer's `compute()` method, then call back out
to an instance method called `_addFixFromBuilder()`, which would drop
the computed change on the floor if `fixKind` was `null`.
This CL contains the following changes to the above system:
* The local `compute()` function and the instance method,
`_addFixFromBuilder()` are combined together, into one instance
method, `_addFromProducer()`.
* Then, the `fixKind` check is moved to the very top of that
method, bailing out _before_ computing changes if `fixKind == null`.
Change-Id: I6c61059fc36ec1587b15ca01b43830a5b179da9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417326
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
While doing specification work for flow analysis, I noticed that in
circumstances where a flow model needs to have both the `split` and
`conservativeJoin` operations applied to it, sometimes flow analysis
applied `split` first, and sometimes it applied `conservativeJoin`
first.
The actual order doesn't matter, since `split` only affects the flow
model's reachability, and `conservativeJoin` only affects the flow
model's variable info. But for the purpose of making the specification
clearer, it's nice to be consistent. This change adjusts the order so
that `split` always happens before `conservativeJoin`.
Change-Id: Ia5dfc9335ee85f122ae274f6bb850f83f12b88d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437060
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL introduces an `IsolateData::asset_base_path` which contains
the fully resolved base path used for assets which are loaded with a
relative path. (Resolving both PATHEXT and symlinks.)
The asset base path is now only resolved once, instead of on every
relative asset load.
The asset base path is now eagerly resolved.
To prevent existing error messages for files not existing changing in
`dartdev` and `Isolate.spawnUri`, files not existing errors are
ignored.
To prevent `tests/standalone/io/named_pipe_script_test.dart` from
failing, failing to canonicalize a file path is treated as no asset
base path rather than reporting a failure.
TEST=pkg/dartdev/test/native_assets/*.dart
Bug: https://github.com/dart-lang/sdk/issues/60946
Change-Id: I79a9144d220dfb3e54311725d41f8f91c88db3a1
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-try,pkg-mac-release-arm64-try,pkg-win-release-arm64-try,pkg-win-release-try,vm-aot-dyn-linux-debug-x64-try,vm-aot-android-release-arm64c-try,vm-aot-linux-debug-x64-try,vm-aot-mac-debug-arm64-try,vm-aot-win-debug-arm64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-msan-linux-release-x64-try,vm-asan-linux-release-x64-try,vm-linux-release-x64-try,vm-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/435421
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Migrate hand-rolled _writeXxxFragment helpers to the shared _writeTemplateFragment. This eliminates duplicated serialization logic (ID / name / offset / modifiers), shrinks the code base, and makes it easier to add new fragment types without boiler-plate.
Removed flags from `bundle_reader` and `bundle_writer`, will remove flag classes in the future as they will be replaced with reading/writing modifiers.
Change-Id: I79aabd1e94bfa831d6718bb2889a6a00e6561112
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437102
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
E.g. when sending 2000 results to a completion request, sending (json
and utf8 encoding) can be a very big part of the cost and it's very
confusing having it attributed to "self" in "request".
Also `mapSuggestions` looked much cheaper than it was because it used
`run` instead of `runAsync`.
Change-Id: Ifd219adb25fa658930548536eb8eb46276acd4a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436922
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Replace eight bespoke implementations for reading fragments with the existing `_readTemplateFragment()` method.
This enforces the consistent use of the template method design pattern, reduces code duplication, and makes future maintenance easier.
Change-Id: If213b146e4b055523432c6d12f36994cac8f38c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436820
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
With this change, CreateMethodOrFunction complies with the contract
that `fixKind` not change before/after `compute()` is called.
This change includes some tidying to simplify the code:
* The decision of whether to use `DartFixKind.CREATE_METHOD` or
`DartFixKind.CREATE_FUNCTION` is solely based on whether the
"target element" is an InterfaceElement. So in the new factory
constructor, we compute the "target element", and save that in a
final field, as well as the fixKind.
* `isStatic` was computed eagerly with other variables in a nest of
else-if bodies. But it is only needed when creating a _method_, and
so it's value can be computed nearer to where it is used.
* `compute()` was ~100 lines long, and a lot of that code was dedicated
to computing the parameter type. Intermediate values like `argument`
and `parameterElement` sort of clutter the local variables; all of
that code can be moved to a function that just computes the
parameter type.
Change-Id: Ibd5d96b752e7e03e52f585bb594c34331b08cdf1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436861
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This is achieved with just a bit of delicacy around commas, braces,
semicolons, and possible super-initializers.
There is exactly one case of a statement that needs to remain in the
constructor body: `_parseTokenPosTable()`.
Additionally I add one helper, `_createServiceObjectListOrNull`, which takes care of some casting and nullability quirks. This also includes one small perf improvement: when `createServiceObject` returns null,
we immediately return an empty list, without wrapping it in `List.from`.
vm_service: helper for list fields
Change-Id: Ic5e36bbfa451bea06edf0d9e684705d392f1ad39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436540
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Work towards #60635
In this change, we rework the AnalysisErrorListener deprecation to
better support users who have their own class that implements
AnalysisErrorListener. This change introduces a sealed supertype,
DiagnosticOrErrorListener, with the old implementation,
AnalysisErrorListener, and the new implementation, DiagnosticListener,
as its sole direct subclasses. Users who have implemented
AnalysisErrorListener should be able to instead implement
DiagnosticListener, and their class is an acceptable instance of
DiagnosticOrErrorListener, wherever that is needed.
In a breaking change we can drop AnalysisErrorListener and deprecate
DiagnosticOrErrorListener, and in the next breaking change, we can drop
DiagnosticOrErrorListener.
For reference, see the first API difference when deprecating AnalysisErrorListener and introducing DiagnosticListener: https://github.com/dart-lang/sdk/commit/903d77cc8229972a424941dcb7b7b79741e833eb#diff-dec15868961d7eadcd009f49d129bebcdb747aaa8dbfde5f5a08884e0cf11e32
Change-Id: I3ccf11d54b41fbca98d020d89978d250c16b4c04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436480
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This CL organizes the commands in the Dart CLI to categories. It
mirrors the categories used in `flutter --help`: `SDK`, `Project`, and
`Tools`. The available command section will now look as follows in
verbose mode:
```
Available commands:
Project
build Build a Dart application including native assets.
compile Compile Dart to various formats.
create Create a new Dart project.
pub Work with packages.
run Run a Dart program.
test Run tests for a project.
Source code
analyze Analyze Dart code in a directory.
doc Generate API documentation for Dart projects.
fix Apply automated fixes to Dart source code.
format Idiomatically format Dart source code.
Tools
compilation-server Control resident frontend compilers.
development-service Start Dart's development service.
devtools Open DevTools (optionally connecting to an existing application).
info Show diagnostic information about the installed tooling.
language-server Start Dart's analysis server.
tooling-daemon Start Dart's tooling daemon.
```
Bug: https://github.com/dart-lang/sdk/issues/60980
Change-Id: Ic9da297fcdd0f8e85d619632ba8ec30fd2c32666
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-arm64-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-arm64-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436382
Reviewed-by: Michael Thomsen <mit@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Update the last known good component after a recompile reject back to
the expected state before the recompile.
Adds tests for expression compilation after recompile accept and
recompile reject cases with `--target=dartdevc`. Similar to existing
tests for the VM.
Removes calls to `_generator.accept()` and
`component.computeCanonicalNames()` from `compileExpressionToJs()`.
These were added very early in the prototype implementation and it is no
longer clear why they would be needed.
Added some additional test cases for expression compilation involving
import resolution because the change that originally added the
`component.computeCanonicalNames()` call implies it was needed for that
reason. See: https://dart-review.googlesource.com/c/sdk/+/138010
TEST=pkg/frontend_server/test/frontend_server_test.dart,pkg/dev_compiler/test/expression_compiler/expression_compiler_test.dart
Change-Id: I9c04bd46e56b33dc654d00fb330de29c3c643a5b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434522
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Paul Berry