Avoid hard coded uses of the name for the SDK runtime library. This
unblocks a more consistent name/rename logic for all dart libraries
when they are imported.
Change-Id: I4599006569ecae81a0526686467e06da9b335fc7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385188
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This test expects that a library no longer being reachable along the import graph causes the library to be removed from the isolate's library list. The incremental kernel files used during reload don't really have a way to express this. The expected semantics also are a bit unsatisfactory. If a library is "deleted" this way, there may still be instances from library floating around, and re-importing the library would be treated like the addition of a new, unreleated library instead of modified the old library kept alive by those instances. Also, if an island of "deleted" libraries have static calls among themselves, those calls stop working because reresolving their targets fails because the "deleted" libraries aren't in the top-level namespace. The mistake of a global namespace continues to inflict damage.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/56785
Change-Id: I743f74d59fd9f017276a118531a58c85ac142ad0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386821
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
In https://github.com/flutter/engine/pull/54714 the "int value" that was used for storing the color values for a Flutter color was removed and replaced with `double red, double green` etc.
The color computer used the `value` field so this stopped it from computing any colors for previews in LSP clients. No tests broke because the tests here use a mock version of the Color class that still had `value`.
This change updates the mock Color class to match the new Flutter implementation, and updates the computer to use the red/green/blue doubles instead of parsing from an int.
It also adds support for the new `Color.from()` constructor that was also recently added.
Fixes https://github.com/Dart-Code/Dart-Code/issues/5289
Change-Id: I3ff20bda0cc848e028822cfcb5a14e6a8f6934d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386802
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
VM has been hiding certain internal implementation types by
converting them to user-visible types in Object.runtimeType.
However, types of record fields were not converted,
which caused inconsistent hashCode of record types.
This change fixes this bug by applying the same type conversion to
types of record fields.
TEST=tests/language/records/type_equality_and_hash_code_test.dart
Fixes https://github.com/dart-lang/sdk/issues/56771
Change-Id: Ie02e76368de0026620d6ab278f49c14e06fd6eda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386542
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
After 3eef6652bf the effect of
the pragma is preserved when inlining so we can apply it
specifically to the method which loads characters.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-product-x64-try,vm-aot-linux-release-x64-try
Change-Id: I63d11fbe5b5f7de965f8859c5db7bde82380cdf5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386201
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously the implementation of this method was a stub.
It turns out that all the necessary infrastructure was in place
already, however the type arguments supplied by MiniAstOperations to
TypeAnalyzerOperationsMixin and TypeAnalyzerOperations needed to be
changed: in the "mini_ast" representation of types, an
InferableParameter is represented by a String, not a
PromotedTypeVariableType. This is because InferableParameter is meant
to represent the declaration of the type parameter
(StructuralParameter for the CFE, TypeParameterElement for the
analyzer), not the type itself. The types used for unit testing in
_fe_analyzer_shared don't have a separate notion of the declaration of
a type parameter, so we just use its name.
Implementing this logic required adding a method
`TypeSystem.matchTypeParameterType`, which checks if a Type is a type
parameter type, and returns the name of the type parameter if so. I
based this on the previously existing `TypeSystem._isTypeVar` method
(which performed the same job but did not return the type parameter
name).
I also took the liberty of fixing a flow analysis test that treated
`T` as a type variable but failed to mark it as a type variable by
calling `addTypeVariable`.
This should help pave the way for unit testing more of the shared
infrastructure for types.
Change-Id: Ia7a9777ec3d90a5886567dcb9f831e388e372f32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386607
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The (utf8) scanner currently has this thing where you give it a
0-terminated byte-array (i.e. you read the file, then allocate
something that's 1 bigger, copy the data, then give it to the scanner)
to 'avoid bounds checks'.
Dart still has bounds checks though - they're just implicit.
As for the string scanner ut gets a string, then creates a new string
like `string + '\x00'` - so basically the same thing.
This CL uses the 'vm:unsafe:no-bounds-checks' pragma, removing the
implicit bounds checks, adding explicit bounds checks,
saving ~73.6 mio instructions when compiling the CFE in the process:
```
Comparing snapshot #1 with snapshot #2
cycles:u: -0.9983% +/- 0.6563% (-174026333.30 +/- 114410028.98)
instructions:u: -0.3416% +/- 0.0005% (-73659267.00 +/- 108567.20)
branch-misses:u: -4.8952% +/- 2.2612% (-3172939.50 +/- 1465641.18)
```
With the scanner-benchmark with `--bytes` I get this:
```
msec task-clock:u: -1.2251% +/- 0.6355% (-50.64 +/- 26.27)
cycles:u: -1.2376% +/- 0.6385% (-223642830.80 +/- 115393789.68)
instructions:u: -2.8155% +/- 0.0000% (-1153243856.00 +/- 428.11)
seconds time elapsed: -1.2165% +/- 0.6408% (-0.05 +/- 0.03)
seconds user: -1.1539% +/- 0.6495% (-0.05 +/- 0.03)
```
With the scanner-benchmark with `--string` I get this:
```
msec task-clock:u: -7.6439% +/- 0.6628% (-366.08 +/- 31.74)
page-faults:u: -95.0034% +/- 0.0014% (-228023.50 +/- 3.41)
instructions:u: 2.1041% +/- 0.0000% (897941907.60 +/- 2082.79)
branch-misses:u: 3.2994% +/- 1.4675% (3239735.30 +/- 1440940.88)
seconds time elapsed: -7.6595% +/- 0.6610% (-0.37 +/- 0.03)
seconds user: -0.8801% +/- 0.7676% (-0.04 +/- 0.03)
seconds sys: -92.0140% +/- 2.8075% (-0.33 +/- 0.01)
MarkSweep( old space) goes from 6 to 0
Notice combined GC time goes from 112 ms to 41 ms (notice only 1 run each).
```
Where I'll note that the 'vm:unsafe:no-bounds-checks' pragma doesn't
(yet?) work for `String.codeUnitAt`.
See https://dart-review.googlesource.com/c/sdk/+/384540
(and https://dart-review.googlesource.com/c/sdk/+/385201) for details.
I assume the relatively big change here is caused by not allocating
a new string with a 0-byte in the end each time.
Note that the read-allocate-copy dance is still performed for the utf8
scanner in this CL as it requires changing all call-sites instead.
It will be done in a follow-up CL where the "end-of-file" int will
likely also be changed to `-1` to (I assume) allow for having the
0-byte in the middle of a file (see also the 10+ year old bug at
https://github.com/dart-lang/sdk/issues/18090)
Note: The pragma (currently?) only has effect in AOT and this change
will (for the utf8 scanner) make the JIT version slower
(probably by the same ~73.6 mio instructions as - at least in AOT -
the implicit check is 6 instructions and the explicit one is 3
instructions). As the pragma doesn't work in the StringScanner anyway
I expect the change to be somewhat equivalent there. Once the
read-allocate-copy dance is also removed from the utf8 scanner I expect
the combined result to be positive all around.
Update: With https://dart-review.googlesource.com/c/sdk/+/385201 landed
I get these changes:
Compiling the CFE:
```
instructions:u: -0.4520% +/- 0.0002% (-98470955.29 +/- 42253.40)
```
Scanner benchmark with `--bytes`:
```
msec task-clock:u: -2.1758% +/- 0.2316% (-92.07 +/- 9.80)
cycles:u: -2.1941% +/- 0.2283% (-405224983.11 +/- 42160655.88)
instructions:u: -3.1049% +/- 0.0000% (-1272360052.95 +/- 706.54)
branch-misses:u: 2.4718% +/- 0.5142% (2371345.23 +/- 493257.76)
seconds time elapsed: -2.1761% +/- 0.2317% (-0.09 +/- 0.01)
seconds user: -2.2071% +/- 0.2308% (-0.09 +/- 0.01)
```
Scanner benchmark with `--string`:
```
msec task-clock:u: -15.0073% +/- 0.2175% (-745.93 +/- 10.81)
page-faults:u: -95.0035% +/- 0.0003% (-228024.25 +/- 0.81)
cycles:u: -7.7986% +/- 0.2329% (-1558985588.99 +/- 46560962.79)
instructions:u: -3.7054% +/- 0.0000% (-1581977447.66 +/- 481.68)
branch-misses:u: -0.6880% +/- 0.5818% (-689453.22 +/- 583101.50)
seconds time elapsed: -15.0198% +/- 0.2170% (-0.75 +/- 0.01)
seconds user: -8.8149% +/- 0.2648% (-0.41 +/- 0.01)
seconds sys: -94.1247% +/- 1.6444% (-0.34 +/- 0.01)
MarkSweep( old space) goes from 6 to 0
```
Change-Id: I524a21f488da7df5dc9d2cdf40112b84896ad3e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383324
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Short explanation: For whatever reason, when using `identical` on `int`s
the ints are first boxed (`BoxInt64`) before being compared
(`StrictCompare`) whereas just doing `==` just does a compare
(`EqualityCompare`).
Results:
With the CFE compiling (a fixed version of) itself I get these results:
```
instructions:u: -0.5756% +/- 0.0003% (-124825401.80 +/- 64013.17)
```
i.e. almost 125 mio instructions saved.
Another run - with 100 iterations each - I get
```
msec task-clock:u: -0.4927% +/- 0.2585% (-20.85 +/- 10.94)
page-faults:u: 0.0174% +/- 0.0139% (18.80 +/- 15.00)
cycles:u: -0.5233% +/- 0.2683% (-91305451.82 +/- 46815747.30)
instructions:u: -0.5754% +/- 0.0002% (-124793061.49 +/- 37426.30)
branch-misses:u: -1.6903% +/- 1.1207% (-1091410.69 +/- 723627.04)
seconds time elapsed: -0.4863% +/- 0.2581% (-0.02 +/- 0.01)
seconds user: -0.4547% +/- 0.3253% (-0.02 +/- 0.01)
```
In the scanner benchmark with `--string` (i.e. using string scanner) I
get these results:
```
msec task-clock:u: -3.7992% +/- 0.3316% (-190.54 +/- 16.63)
cycles:u: -4.1423% +/- 0.3566% (-836808313.28 +/- 72033424.19)
instructions:u: -3.3524% +/- 0.0000% (-1480262370.08 +/- 828.58)
branch-misses:u: -1.7591% +/- 0.9582% (-1781144.28 +/- 970258.82)
seconds time elapsed: -3.7988% +/- 0.3303% (-0.19 +/- 0.02)
seconds user: -4.0211% +/- 0.4161% (-0.19 +/- 0.02)
```
(Just running the benchmark also sees the characters/µs go from ~93 to
~97).
In the scanner benchmark with `--bytes` (i.e. using the utf8 scanner) I
get these results:
```
msec task-clock:u: -4.2872% +/- 0.4467% (-185.64 +/- 19.34)
cycles:u: -4.2972% +/- 0.4382% (-812955454.92 +/- 82892232.23)
instructions:u: -3.4867% +/- 0.0000% (-1479744935.28 +/- 297.12)
seconds time elapsed: -4.2872% +/- 0.4470% (-0.19 +/- 0.02)
seconds user: -4.2204% +/- 0.4730% (-0.18 +/- 0.02)
```
(Just running the benchmark also sees the bytes/µs go from ~108 to ~113).
In both cases we notice how the actual time, cycles and instructions
agree pretty well.
Combining the data for the compile and the benchmark I assume this CL
actually reduces the runtime of the CFE compiling itself by a about
half a percent.
Change-Id: I67d056837240aef61b6707d02507ab4121b31715
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385940
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
E.g. we might do this
```
$ out/ReleaseX64/dart-sdk/bin/dart compile aot-snapshot pkg/_fe_analyzer_shared/test/scanner_benchmark.dart
Generated: /usr/local/google/home/jensj/code/dart-sdk/sdk/pkg/_fe_analyzer_shared/test/scanner_benchmark.aot
$ for type in --bytes --bytes0 --string --stringtobytes --count ; do out/ReleaseX64/dart-sdk/bin/dartaotruntime pkg/_fe_analyzer_shared/test/scanner_benchmark.aot pkg/kernel/lib/ast.dart $type; done
Scanned 466534 bytes 1000 times in 0:00:04.413011
Found errors 0 times
That's 105.71784208106438 bytes per microsecond
Scanned 466534 bytes 1000 times in 0:00:04.911947
Found errors 0 times
That's 94.97944501437007 bytes per microsecond
Scanned 466532 string characters 1000 times in 0:00:05.413169
Found errors 0 times
That's 86.18463602374136 string characters per microsecond
Scanned 466532 string characters as bytes 1000 times in 0:00:06.722731
Found errors 0 times
That's 69.39620222793386 string characters as bytes per microsecond
Scanned 466534 bytes 1000 times in 0:00:00.641854
Found errors 0 times
That's 726.8537704836302 bytes per microsecond
```
to see that scanning pre-0-at-the-end'ed bytes scan at ~105 bytes/µs,
doing a copy to add the 0 at then end, then parse bytes scan at ~95,
scanning strings runs at ~86, converting strings to bytes, then scanning
the bytes at ~69 and - for comparision - just running through the bytes
counting linebreaks runs at ~726.
The benchmark is also useful for comparing optimizations.
Change-Id: I67c12850505e7f712660fd353575e8c7a455f112
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
In the Flutter engine, we plan to expand and start using Dart actions to
rely more on the GN build system, and less on home-grown (Python/Bash)
tooling. To that end, we'll start generating dart_snapshot and dart_test
rules that are invokved the same way locally (via `et`) and on CI, with
a goal of making all of our tests programatically discoverable.
We need the `metadata` field (a standard GN field) in order to tag our
outputs (i.e. `metadata = { action_type = ['dart_executable'] }`);
see https://gn.googlesource.com/gn/+/main/docs/reference.md#var_metadata.
Bug: https://github.com/flutter/flutter/issues/147013
Change-Id: I0e44209b8aade13cec99b944583a90a7c13d3300
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386582
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This was done in the feature specification in v1.10, but it wasn't
done in the specification parser at the time. This CL corrects that
omission.
Change-Id: I03d54e8f6a369abd5d2be8fb281e8f3abd2cb85d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386240
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Currently when the .wasm file path passed to run_wasm.js is a relative
path, `Uri.base` becomes something like `file://test.wasm`, which is not
a valid file URI, so it causes crashes in `Uri.toFilePath`.
When the file path is relative add a omit `file://` prefix.
`Uri.base` values before and after:
- Before, relative .wasm path: `file://test.wasm` (invalid)
- Before, absolute .wasm path: `file:///home/user/test.wasm`
- After, relative .wasm path: `test.wasm` (fixed)
- After, absolute .wasm path: `file:///home/user/test.wasm` (same as before)
Change-Id: I0d1c43716e07a9ee926e7feeeab514c2c66bac16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385700
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Follow-up to https://dart-review.googlesource.com/c/sdk/+/384540
allowing the removal of bounds checks for `String.codeUnitAt` if the
method it is called from is annotated with
`@pragma('vm:unsafe:no-bounds-checks')`.
Done by the inliner providing the calling function to the flow graph
builder and GenericCheckBound instruction utilizing this information.
TEST=Existing tests; added runtime/tests/vm/dart/no_bound_check_il_test.dart
Change-Id: Ic6144b0b8400ec6532fb58cd5fd9b3dcdb9a2ff9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385201
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Nicholas Shahan