When running the test from Powershell Platform.executable is absolute path, rather than relative when invoked from Command shell. That breaks the test when running from Powershell.
This change fixes the test to always use Platform.resolvedExecutable.
```
PS C:\src\d\sdk> out\DebugX64\dart.exe tests\ffi\native_assets\infer_native_assets_yaml_dart_kernel_snapshot_test.dart
invoke helper with --package=...
File copied to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_b0de5819/infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.
Unhandled exception:
Unsupported operation: Cannot extract a file path from a c URI
<asynchronous suspension>
<asynchronous suspension>
<asynchronous suspension>
<asynchronous suspension>
<asynchronous suspension>
PS C:\src\d\sdk>
```
after
```
PS C:\src\d\sdk> out\DebugX64\dart.exe tests\ffi\native_assets\infer_native_assets_yaml_dart_kernel_snapshot_test.dart
invoke helper with --package=...
File copied to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_3dfd90fc/infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.
File native_assets.yaml written to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_3dfd90fc/.dart_tool/native_assets.yaml.
dill file created: file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_3dfd90fc/infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.dill
invoke helper with --package=... done
invoke helper in working dir
File copied to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_c7f57eac/infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.
File native_assets.yaml written to file:///C:/Users/aam/AppData/Local/Temp/tests_ffi_native_assets_c7f57eac/.dart_tool/native_assets.yaml.
dill file created: infer_native_assets_yaml_dart_kernel_snapshot_helper.dart.dill
invoke helper in working dir done
```
TEST=ci, manually from powershell.
Change-Id: Ie0d6cdb2ecdd69bb44a8ea820ce71405344c1307
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429080
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
This makes it easier for me to find diagnostics that still need to be
documented because I can search for 'hasPublishedDocs: false'. It's
hard to search for places where it isn't specified.
In case you're interested, we currently have documentation for 70% of
the diagnostics represented in this file.
In almost every case the value is `false`, but there are two codes whose
documentation has already been published but which were not marked as
such. This means that we weren't associating a URL with the diagnostic,
but that's now been fixed.
Change-Id: I4e17671e319ec8e8887aacb6758594d7962bfc85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429202
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This was previously available as an extension on this class, but we
control the class quite directly. Seems like it should just be an API
of LinterContext.
Change-Id: I9fb61ab4471e859c39d9fa963eed2a3839fca617
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428925
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
* All callers are migrated off of `AbstractAnalysisRule.lintCodes`
and `.reporter`.
* All callers are migrated off of `AnalysisRule.lintCode`.
Change-Id: I4123250c33ff1d0a488bd4457cfe5fc13160e829
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429121
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
When a synchronous function body has an `await` expression, we report
an error. We don't need to _also_ report a lint.
The noted error, `CompileTimeErrorCode.AWAIT_IN_WRONG_CONTEXT`, already
is associated with the "add async" fix. Reporting a lint when an error
is also definitely reported is just double reporting.
Change-Id: If6d260a01cc654c87897480996d3f6f4b61373dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429063
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Luckily, the two cases which were reported could both be remedied by
making more things private.
* `DartFileEditBuilderImpl.librariesToImport` exposed `_LibraryImport`,
but could be made private anyhow. Also, it's package-private code,
so this is not a breaking change.
* `CodegenVisitor.generateConstant` accepted a private type as an
argument, but the whole class can be made private.
Change-Id: I8613812385ed0e9a7e36922d86889dad4cedf3cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428924
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
In VSCode, when the user hovers over a reference to `dart:core`
(e.g. an instance of a core type such as `String`), this triggers
VSCode to briefly open, and then close, one of the core files defining
the SDK; this in turn causes it to send notifications to the analysis
server to create and then destroy an overlay for the core SDK file.
This leads to a somewhat rare race condition: if the analyzer pumps
its event queue between receiving the notifications to create and
destroy the overlay, and there isn't adequate time in between these
two events for all active analysis drivers to re-build their library
readers, then what will happen is that
`LinkedElementFactory.removeLibraries` will get passed a `uriSet` that
contains `dart:core` but not `dart:async`. (The reason is because the
driver hasn't yet rebuilt the library cycles, so it doesn't know that
`dart:core` and `dart:async` are in the same cycle).
Before this change, `LinkedElementFactory.removeLibraries` contained a
safety check that would throw an exception if the `uriSet` ever
contained `dart:core` but not `dart:async`. Due to the race condition,
this safety check would occasionally fire, crashing the analyzer. (On
my machine, the crash would occur about once per day on average).
This safety check was incorrect (since it checked for a condition that
was thought never to occur, but in fact does occur). Also, it was not
necessary; since the only way for the race condition to occur is if
the driver hasn't yet rebuilt its library cycles, there is no harm in
removing just `dart:core` and not `dart:async`, as both have
previously been removed. And, indeed, the incorrect safety check has
always been followed by a (correct) safety check making sure that if
`dart:core` is ever removed, then after the removal, the set of
library readers is empty.
For the last month, I've been running a local build of the analyzer
with the incorrect safety check removed, and I haven't observed any
crashes.
Fixes https://github.com/dart-lang/sdk/issues/48051.
Bug: https://github.com/dart-lang/sdk/issues/48051
Change-Id: I611269ea7596cc63af5eb77d5baf641454a9d315
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428902
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This remove the iterators from the NameSpace interface and instead
collects the list of builders belonging to a library or declaration
directly inside these builders.
Adds ComputedNameSpace for import, export and prefix name spaces. This
allows for replacing a member and has a filteredIterator function. These name spaces are computed from import/exports and therefore need to be iterated through directly and replace builder when two builders collide.
Change-Id: Iec974656c5331498aa1cfca7973300ac6e044994
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428820
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Comparing a before and an after aot-compiled analysis server,
running each 25 times, via `pkg/front_end/tool/benchmarker.dart`:
```
out/ReleaseX64/dart pkg/front_end/tool/benchmarker.dart \
--iterations=25 \
--snapshot=pkg/analysis_server/bin/server.aot.2 \
--snapshot=pkg/analysis_server/bin/server.aot.3 \
--arguments="--disable-file-byte-store" \
--arguments="--train-using" \
--arguments="pkg/front_end/lib/"
```
(where `server.aot.2` is an aot-compile of the parent CL and
`server.aot.3` is an aot-compile with this CL) gets this result:
```
msec task-clock:u: -1.5762% +/- 0.7803% (-131.97 +/- 65.33) (8372.91 -> 8240.93)
page-faults:u: 0.7490% +/- 0.1986% (1161.20 +/- 307.82) (155028.84 -> 156190.04)
cycles:u: -1.6791% +/- 0.8074% (-586734139.48 +/- 282150958.07) (34944191636.32 -> 34357457496.84)
instructions:u: -2.0051% +/- 0.0614% (-926171189.36 +/- 28378206.66) (46190016825.56 -> 45263845636.20)
seconds time elapsed: -1.5786% +/- 0.7789% (-0.13 +/- 0.07) (8.39 -> 8.26)
seconds user: -1.5335% +/- 0.7902% (-0.12 +/- 0.06) (8.02 -> 7.89)
Scavenge( new space) goes from 134 to 131
MarkSweep( old space) goes from 1 to 0
Evacuate(store buffer) goes from 1 to 0
Notice combined GC time goes from 2766 ms to 2664 ms (notice only 1 run each).
```
This seems quite high and is more than I've gotten before rebases etc, so I'm guessing this has been lucky with GCs or something.
Running it on `pkg/analyzer/lib/` instead (only 5 times) I get:
```
msec task-clock:u: -2.1880% +/- 1.2579% (-227.09 +/- 130.55) (10378.74 -> 10151.65)
cycles:u: -2.2829% +/- 1.3197% (-988942892.00 +/- 571677673.33) (43320229255.60 -> 42331286363.60)
instructions:u: -1.9075% +/- 0.5803% (-1080089151.00 +/- 328577465.65) (56624410628.20 -> 55544321477.20)
seconds time elapsed: -2.1807% +/- 1.2533% (-0.23 +/- 0.13) (10.39 -> 10.17)
seconds user: -1.9061% +/- 1.4734% (-0.19 +/- 0.15) (9.94 -> 9.75)
Scavenge( new space) goes from 168 to 164
MarkSweep( promotion) goes from 17 to 15
MarkSweep( old space) goes from 4 to 2
Notice combined GC time goes from 3228 ms to 3723 ms (notice only 1 run each).
```
which looks ~similar though so I don't know.
Change-Id: I21c9dd6fd5e122f65ec596551af8a2ec464d3920
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428320
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The subtype checking mode that ignores the nullability and is enabling
the nullability-related messaging is to be removed. This CL cleans up
the test expectations for that change.
Change-Id: I39e1fbf40192d1434b87e38cbe00eb68a965f0df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428782
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Adding edits (e.g. via `dart fix --apply` are often done with
`List.insert(0, whatnot)` which takes O(n) time.
Here QueueList that can insert fast at both ends is used instead
(and we use `addFirst` instead of `insert(0)`.
On the example from
https://github.com/feinstein/google-i18n-address-dart.git we go from:
```
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 3m55.810s
user 4m1.209s
sys 0m3.714s
(resetting)
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 3m33.966s
user 3m37.588s
sys 0m2.058s
(resetting)
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 3m36.525s
user 3m40.083s
sys 0m1.907s
```
to:
```
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 0m9.970s
user 0m12.676s
sys 0m2.100s
(resetting)
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 0m9.862s
user 0m12.926s
sys 0m1.797s
(resetting)
$ time dart fix --use-aot-snapshot --apply
[...]
249517 fixes made in 255 files.
real 0m9.612s
user 0m12.712s
sys 0m1.834s
```
Statistics on the `real` runtime:
```
N Min Max Median Avg Stddev
x 3 213.966 235.81 216.525 222.10033 11.941664
+ 3 9.612 9.97 9.862 9.8146667 0.18363369
Difference at 95.0% confidence
-212.286 +/- 19.1415
-95.581% +/- 8.61838%
(Student's t, pooled s = 8.44503)
```
For `lsp_many_prefer_single_quotes_violations_benchmark.dart --sizes=3200`:
Before from something like:
```
Initial analysis: 0.115654
First code action call: 0.835152
Subsequent action call 1: 0.538592
Subsequent action call 2: 0.561636
Select all code action call: 1.564402
```
After to something like:
```
Initial analysis: 0.086985
First code action call: 0.411660
Subsequent action call 1: 0.171566
Subsequent action call 2: 0.193708
Select all code action call: 1.107339
```
Statistics on 5 runs gives:
First code action call:
```
Difference at 95.0% confidence
-0.44381 +/- 0.0261597
-52.4602% +/- 3.09218%
(Student's t, pooled s = 0.0179367)
```
Subsequent action call 1:
```
Difference at 95.0% confidence
-0.381012 +/- 0.0195618
-69.9139% +/- 3.5895%
(Student's t, pooled s = 0.0134128)
```
Subsequent action call 2:
```
Difference at 95.0% confidence
-0.360077 +/- 0.0265277
-64.634% +/- 4.76173%
(Student's t, pooled s = 0.0181891)
```
Select all code action call:
```
Difference at 95.0% confidence
-0.405855 +/- 0.027662
-26.7277% +/- 1.82169%
(Student's t, pooled s = 0.0189668)
```
Change-Id: I3868afaa8c32a24c01c3a52bd8a53d5e8e4e3afe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427401
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL introduces variance-dependent treatment of the `Handle` native
type when converting native types to Dart types. Since `Handle` can
represent any object, it should match any type. To achive that in
cases when `Handle` appears as the subtype in the subtype checks, it's
converted to `Never` in covariant positions and to `Object?` in
covariant ones.
TEST=existing
Issue https://github.com/dart-lang/sdk/issues/49518
Change-Id: Ie16a210491ada80d21f4d0f1c0fa3b3804881ede
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426880
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Every declaration annotated with `@generated` was generated. In the
current version there are `2180` such declarations. For comparison,
there are `2167` instances of `@override` in total, and `@generated +
@override` has `1576` instances, so we generate `72%` of all overrides.
The generator automatically formats and sorts `ast.dart` after applying
changes, so the result is nice and clean. We run a separate DAS instance
from the script to do this.
Things to improve in the future:
1. Generate for non-leaf classes.
2. Support for `DoNotGenerate`.
Change-Id: I05e6356c9aac68449d5117ad8fd533735f130c73
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427481
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
When cone type has a large number of allocated subtypes, TFA uses
symbolic wide cone type as a faster approximation to speed up
the analysis.
Intersection of wide cone type C1+ with cone type C2+ when
there is no subtyping relation between C1 and C2 results in
approximate type C1+. As a result, analysis may fail to determine
that certain type test will never succeed.
This change improves precision of cone and wide cone intersections
and unions in case cone type has an empty specialization
(no allocated subtypes).
TEST=pkg/vm/testcases/transformations/type_flow/transformer/regress_60733.dart
Fixes https://github.com/dart-lang/sdk/issues/60733
Change-Id: I51287d38a9e5f3c0ce88dab358d0825843a0de03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428840
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Martin Kustermann