The constant evaluator is only intended to visit expressions but
by extending RecursiveResultVisitor falsely gave the impression that it
supported visitor all nodes.
Change-Id: Id6afc2b2c51dd4dee1327f8df2b20a6fae6d2c91
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/189060
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
This CL plumbs the types of `this` and property get expression from
the CFE and analyzer into flow analysis, so that flow analysis will be
able to create more accurate "why not promoted" information for those
expression types. This made it possible to eliminate a clumsy aspect
of the previous implementation, namely that we would consider a
promotion attempt like `if (x.y == null) return;` as an attempt to
promote the type of `x.y` to `Object`; now we compute the type the
user is actually trying to promote to, so we will be able to generate
more accurate "why not promoted" messages.
Bug: https://github.com/dart-lang/sdk/issues/44898
Change-Id: I67f9fc59e72103194a1ea6b1c4dfeae8aeb194a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187064
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Before this CL, using extenral fields with the advanced invalidation
would crash when serializing because the wrong reference was used
when recompiling.
The reference has been updated and the wrong ones renamed for more
clarity.
Change-Id: I2557a2ae17c6bf7e99afa2a52b09060a0160dee3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188461
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The CFEs FormattedMessage always had two getters to get the text inside
one that would supposedly give an ansi formated version of the message
and one that would supposedly give a plaintext formated version of the
message. They both returned the same string, though, which would either
be with ansi escape codes or plain text depending on the environment at
compile time.
This CL fixes that by having both messages, and letting the reporting
(i.e. whenever the message is read) decide which to use. That way we
can - for instance - report errors with color if the terminal supports
it correctly when reusing a dill (and reissuing problems, but where the
terminal support changes) and if printing the problem to an html <pre>
field (like observatory does).
It also cleans up two different implementations of whether we think
the terminal supports colors or not, by deleting one of them.
This is the second try. Patchset #1 is the original.
Patchset #2(and possibly beyond) is the changes.
TEST=Existing test suites.
Change-Id: I8e483049ce81ce1bd8e5396b588a31e0ad3a8630
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187402
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Allowing usage of generated experiment flag in the expression_generator, body_builder and eventually, constant_evaluator.
Wanted to keep this CL relatively small and separated from the actual
usage of the flag. Will do that in an upcoming CL.
Change-Id: Ia7c51381496bbde6d25eb47ee1b5cba0e3d7e0cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186620
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Adds support for single dimension inline arrays in structs. Multi-
dimensional arrays will be supported in a future CL.
This CL adds:
- CFE static error checks for inline arrays.
- CFE transformations for inline arrays.
- VM consumption of inline array fields for NativeType.
- Test generator support for inline arrays + generated tests.
Previous CLs added support for inline arrays in:
- analyzer https://dart-review.googlesource.com/c/sdk/+/183684
- updated in this CL to new API.
- ABI calculation https://dart-review.googlesource.com/c/sdk/+/183682
Closes: https://github.com/dart-lang/sdk/issues/35763
Open issue: https://github.com/dart-lang/sdk/issues/45101
CFE transformations are tested with expectation files:
TEST=pkg/front_end/testcases/(.*)/ffi_struct_inline_array.dart
Trampolines and CArray API are tested with end-to-end Dart tests:
TEST=tests/ffi(_2)/(.*)by_value(.*)test.dart
TEST=tests/ffi(_2)/inline_array_test.dart
Compile-time errors (both CFE and analyzer) are tested in:
TEST=tests/ffi(_2)/vmspecific_static_checks_test.dart
Change-Id: I014c0e4153f1b885638adce80de6ab3cac8e6bb2
Cq-Include-Trybots: luci.dart.try:dart-sdk-linux-try,dart-sdk-mac-try,dart-sdk-win-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-mac-debug-x64-try,vm-kernel-linux-debug-ia32-try,vm-kernel-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,vm-kernel-nnbd-mac-release-x64-try,vm-kernel-nnbd-win-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-nnbd-linux-debug-x64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-win-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,vm-kernel-msan-linux-release-x64-try,vm-kernel-precomp-msan-linux-release-x64-try,vm-kernel-precomp-android-release-arm_x64-try,analyzer-analysis-server-linux-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183640
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
This reverts commit f63f7736c5.
Reason for revert: This somehow breaks the Windows bots. `python tools/test.py -n dartk-win-release-x64 standalone_2/io/process_shell_test`.
Original change's description:
> [cfe] Actually have both ansi and plain text formatted messages
>
> The CFEs FormattedMessage always had two getters to get the text inside
> one that would supposedly give an ansi formated version of the message
> and one that would supposedly give a plaintext formated version of the
> message. They both returned the same string, though, which would either
> be with ansi escape codes or plain text depending on the environment at
> compile time.
>
> This CL fixes that by having both messages, and letting the reporting
> (i.e. whenever the message is read) decide which to use. That way we
> can - for instance - report errors with color if the terminal supports
> it correctly when reusing a dill (and reissuing problems, but where the
> terminal support changes) and if printing the problem to an html <pre>
> field (like observatory does (1)).
>
> It also cleans up two different implementations of whether we think
> the terminal supports colors or not, by deleting one of them.
>
> (1) At least sometimes. It works - I think - only for 'evaluateInFrame',
> but that's another story (and will be fixed in a follow-up CL).
>
> TEST=Existing test suites.
>
> Change-Id: Iedaedd9a5c41458d40c23ed4b706324c004ae943
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186291
> Commit-Queue: Jens Johansen <jensj@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
Change-Id: I0b53f943a61f76705badfead30d9e1ee35baff57
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186941
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The CFEs FormattedMessage always had two getters to get the text inside
one that would supposedly give an ansi formated version of the message
and one that would supposedly give a plaintext formated version of the
message. They both returned the same string, though, which would either
be with ansi escape codes or plain text depending on the environment at
compile time.
This CL fixes that by having both messages, and letting the reporting
(i.e. whenever the message is read) decide which to use. That way we
can - for instance - report errors with color if the terminal supports
it correctly when reusing a dill (and reissuing problems, but where the
terminal support changes) and if printing the problem to an html <pre>
field (like observatory does (1)).
It also cleans up two different implementations of whether we think
the terminal supports colors or not, by deleting one of them.
(1) At least sometimes. It works - I think - only for 'evaluateInFrame',
but that's another story (and will be fixed in a follow-up CL).
TEST=Existing test suites.
Change-Id: Iedaedd9a5c41458d40c23ed4b706324c004ae943
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186291
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
In the course of implementing "why not promoted" support, I am having
trouble following the various error cases in type_inferrer.dart and
when they're triggered, so I decided to start adding short comments
illustrating how they each one arises. I'll add more comments as the
implementation gets further along and I cover more error cases.
Change-Id: Icde498a4b884e1725cf98f8b9312879a696916bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185841
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Make Extension.name non-nullable
Make Class.name non-nullable
Make Extension.onType late non-nullable
Make LabeledStatement.body late non-nullable
Make SwitchCase.body late non-nullable
Change-Id: Iccf21fc800faa620c5d4b7bea68f74eec8bf62e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185083
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL completes the migration of the first wave of
interdependent libraries in package:kernel, including ast.dart.
In order to ensure non-nullability on AST properties, the Transformer
has been split in 2 variants: Transformer which doesn't support
removal of nodes and RemovingTransformer which supports removal where
allowed by the context using 'removal sentinels'.
Start reviewing Transformer and RemovingTransformer in visitors.dart
since many of the changes are caused by the changes here.
Included in the migration are the mixin_deduplication.dart and
unreachable_code_elimination.dart since these needed porting to
the RemovingTransformer which was aided by opting in the libraries
which only depended on ast.dart.
TEST=existing
Change-Id: I9e63b985bd24896c25edd4ee51e37770187bcc17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184786
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
The front end previously enforced a stricter-than-spec requirement on
conflicting imports on its own code. The check was included of the
kernel snapshot and therefore always enforced, even in published sdks.
The extra check was removed a month ago and now tools/sdks/ have been
updated to use a later version of the sdk, so the unneeded hide
combinators can now be removed from the source code.
Closes#44667
TEST=existing
Change-Id: I1d1053b1ef9a40b6a918eef515a02d7b404906c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185084
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This CL changes the semantics of
`Pointer<T extends NativeType>.elementAt` and
`sizeOf<T extends NativeType>` to use the compile-time `T` rather than
the runtime `T`.
Issue: https://github.com/dart-lang/sdk/issues/38721
TEST=tests/ffi/data_test.dart
TEST=tests/ffi/sizeof_test.dart
TEST=tests/ffi/structs_test.dart
TEST=tests/ffi/vmspecific_static_checks_test.dart
Change-Id: Ifb25a4bd66d50a385d3db6dec9213b96dff21722
Cq-Include-Trybots: luci.dart.try:vm-precomp-ffi-qemu-linux-release-arm-try,analyzer-analysis-server-linux-try,analyzer-linux-release-try,analyzer-nnbd-linux-release-try,front-end-linux-release-x64-try,front-end-nnbd-linux-release-x64-try,benchmark-linux-try,dart-sdk-linux-try,pkg-linux-release-try,vm-ffi-android-release-arm-try,vm-ffi-android-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178200
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This CL:
* Makes the standard filesystem more synchronous by default.
This makes reading files for normal compiles faster.
* Adds a more asynchronous version of `exists` and `readAsBytes`.
This potentially allows for reading files faster when in a context
where the files can actually be read in parallel. The client have
to make the choise though.
* Skips `Uri.base.resolveUri` when the uri has a scheme. This makes it
slightly faster in my tests, but does not remove any `.` and `..`.
Having those when having a scheme seems sort of weird though.
If this turns out to be a problem we can add it back.
* Re-orders what the standard filesystem checks in `exists` to assume files
which seems more likely to happen. This - for files - means less checks
and should make checking for existance faster. (This was noticed by Siggi).
Using the same measurement procedure as in
https://dart-review.googlesource.com/c/sdk/+/85442
timing how long fasta spends on *reading* files when compiling dart2js
(when compiling via the VM) I get a good speedup.
Note that the measurements are in microseconds:
Before this CL (run like `out/ReleaseX64/dart pkg/compiler/bin/dart2js.dart 2>&1 | grep "Read file (total)" | tail -n 1` 10 times):
Read file (total): 94678
Read file (total): 94232
Read file (total): 91726
Read file (total): 77472
Read file (total): 95582
Read file (total): 88113
Read file (total): 89245
Read file (total): 91575
Read file (total): 96291
Read file (total): 95730
With this CL (run like `out/ReleaseX64/dart pkg/compiler/bin/dart2js.dart 2>&1 | grep "Read file (total)" | tail -n 1` 10 times):
Read file (total): 68379
Read file (total): 69320
Read file (total): 72930
Read file (total): 69692
Read file (total): 68685
Read file (total): 73548
Read file (total): 64649
Read file (total): 71951
Read file (total): 73486
Read file (total): 70621
Difference at 95.0% confidence
-21138.3 +/- 4193
-23.111% +/- 4.5843%
(Student's t, pooled s = 4462.56)
Furthermore, using an internal benchmark (discussed in an email thread)
I get these numbers (note that the measurements are in milliseconds):
before:
4453
4249
4187
4190
4216
after:
2310
2379
2449
2467
2407
Difference at 95.0% confidence
-1856.6 +/- 131.443
-43.5924% +/- 3.08625%
(Student's t, pooled s = 90.1257)
Using the asynchronous versions of exists and readAsBytes and checking for
existance and reading in parallel on the same internal benchmark it gets to
1137
1185
1067
1089
1189
For completion, comparing to using "raw" `File` (again using the internal benchmark):
sequential standard
2377
2419
2485
2373
2431
sequential io_sync
2279
2182
2237
2312
2324
io_sync faster:
-150.2 +/- 76.3122
-6.21432% +/- 3.15731%
(Student's t, pooled s = 52.3245)
sequential standardasync
4865
4915
4753
5185
4760
sequential io_async
4746
4834
4989
4840
4891
No difference proven at 95.0% confidence
parallel standard
2526
2563
2652
2616
2685
parallel io_sync
2335
2184
2244
2341
2401
io_async faster
Difference at 95.0% confidence
-307.4 +/- 111.037
-11.785% +/- 4.25691%
(Student's t, pooled s = 76.1341)
parallel standardasync
1137
1185
1067
1089
1189
parallel io_async
1105
1088
1145
1048
1113
No difference proven at 95.0% confidence
TEST=Existing tests.
Change-Id: I8ba56ab0768df8672bcdb693782d3f1eec86b683
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185101
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
The MergeVisitor was trying to merge FunctionType.typedefType in order
to merge function types, thus preventing nnbd top merge of two
compatible types that were just introduced through different typedefs
or function type syntax.
Change-Id: Icea75598168c86ed33314db22ebeec3e666c3675
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184785
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
package:vm "clones" an old incremental compiler when creating a new one
for a new isolate. It does that by calling .computeDelta on the first
available compiler. If that compiler is already compiling, though, things
can go bad.
The risk of that happening was made bigger by awaiting in the standard
filesystem instead of using the sync filesystem operations, but it can
happen either way.
If it has any practial importance (outside of tests) is an open quesiton
but this should nevertheless fix the issue by only letting the
incremental compiler allow one compile at the time (creating an implicit
queue when more is tried).
TEST=Existing test suites + added test.
Change-Id: I694e360aa4bce604db41908730c66ef3b96e6d8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184788
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
When reporting that a null check is needed due to a lack of type
promotion, and the thing that was not promoted was a reference to a
field or property, the CFE and analyzer now report "why not promoted"
using a context message that points to the definition of the field or
getter. (Previously the CFE reported a context message with no
location, and the analyzer didn't report "why not promoted").
Bug: https://github.com/dart-lang/sdk/issues/44898
Change-Id: If1841727b8b60dd87c43f239e6a06b98f363801f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184522
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is in preparation to migrate package:kernel to null safety.
For the visitor interfaces to support non-nullable return types, the
implementations must avoid using `null` as return value in its base case.
TEST=Refactoring
Change-Id: Ie8fa5d41b99850d9e4abb59634c72920c64128d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183691
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Johnni Winther