This change adds propagation of closure values to TFA.
For now, inferred closure values are used only when they are
constant (tear-off of a static method or a constructor).
Arbitrary closures can now be referenced from unrelated
members via closure-id metadata.
In addition, this change fixes an incorrect stack trace when
an implicit closure (tear-off) was propagated and its call was
inlined. Inlining interval was not recorded because of the missing
source position of a call to a target method within implicit closure.
TEST=pkg/vm/testcases/transformations/type_flow/transformer/closures.dart
Issue: https://github.com/dart-lang/sdk/issues/39692
Change-Id: I3590da91b6057e0b55a8614382dba1bbcc267b39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325447
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This CL passes the offset and uri of the file (here called a script uri
as opposed to a library uri, the two will be different if we're in a
part) when doing expression compilation.
This CL only passes the data, but doesn't actually use it.
Future CL(s) will use this data to calculate the static type of
available variables which is needed for an upcomming feature.
TEST=Existing tests.
CoreLibraryReviewExempt: Not changing SDK APIs.
Change-Id: I67ead461ab4bb9341424e693946f3e4afe35ce92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329322
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This change moves inferred types of incoming arguments to a separate
metadata. Incoming argument type may be different from inferred
type of a parameter variable as parameter variable could be
modified in the method body.
This is a preparation for adding inferred types of captured
variables - parameter variable can be captured and can have both
inferred type of incoming argument and inferred type of a captured
variable.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/51102
Change-Id: I9f77b8f5ed87477424f4fd3d339fdfb8e55abf82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320121
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Creation of AppJit snapshot will not include the source of [Script]
objects (see `UntaggedScript::snapshot_to`). As a result there's no
point in letting the CFE embed the sources into the kernel if we
only use it to create an AppJit snapshot.
This is also in line with build rules for our dart-sdk, where we do the
kernel compilation separately, see utils/application_snapshot.gni:
```
template("application_snapshot") {
...
# Build the kernel file using the prebuilt VM to speed up the
# debug and simulator builds.
prebuilt_dart_action(target_name + "_dill") {
...
args = [
...
"--no-embed-sources",
...
]
[[[
}
...
}
```
TEST=ci
Change-Id: I4e17e49dc21af6102d62c2278dbd6ebbe387f7e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313560
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Right now `utf8.encode()` has a static return type of `List<int>`
due to extending `Encoding` (which extends `Codec<String, List<int>>`).
We cannot easily change `Encoding` to extend `Codec<String, Uint8List>`
because that would also change `utf8.decode()` to require `Uint8List`
which would be a breaking change.
So instead we override `utf8.encode()` to have more precise return type.
Some parts of our SDK are run using the checked-in SDK, so it cannot
rely on the changed return type yet (until checked-in SDK is rolled).
So we use `const Utf8Encoder().convert()` as a temporary change, as
that already has `Uint8List` return type.
Issue https://github.com/dart-lang/sdk/issues/52801
TEST=ci
CoreLibraryReviewExempt: More precise return type for existing API
Change-Id: I2861d1f0eb3d292d8e3ec8437c0d441a2d2bd193
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254903
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Before this CL, the kernel_service was recursing one level up to find
a `.dart_tool/native_assets.yaml` due to a typo.
This tests adds a unit test to cover the discovery.
TEST=pkg/vm/test/kernel_service_test.dart
This CL also undoes a spurious change in another test.
Change-Id: Ie7440a2768f8cd6c1195cf31863c8a7fff29e394
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/285681
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
The VM can read native asset mappings from kernel.
Previous CLs already added support to embed native asset mappings for
one-shot compilation.
This CL adds support for adding native assets mappings to kernel files
created by the frontend_server with the incremental compiler.
The frontend_server accepts a `--native-assets=<uri>` at startup and
accepts a `native-assets <uri>` message on stdin as compilation
command.
The frontend_server caches the compiled native assets library.
When a `reset` command is sent to request a full dill from the
incremental compiler, the native assets mapping is taken from the
cache and added to the final dill file.
Split of DartSDK & flutter_tools prototype to land separately.
TEST=pkg/frontend_server/test/native_assets_test.dart
Bug: https://github.com/dart-lang/sdk/issues/49803
Bug: https://github.com/dart-lang/sdk/issues/50565
Change-Id: I6e15f177564b8a962e81261815e951e7c9525513
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/282101
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Adds support for `asset: 'asset-id'` in `FfiNative`s.
Symbols in assets are resolved by
1. the provided [asset] (the bulk of this CL),
2. the native resolver set with `Dart_SetFfiNativeResolver` in
`dart_api.h` (old behavior), and
3. the current process.
Symbols in assets are resolved by the Dart VM through the mapping
provided in the `vm:ffi:native_assets` library:
```
@pragma('vm:ffi:native-assets', {
"linux_x64": {
"<asset1>": [
"absolute",
"<absolute-path>"
],
"<asset2>": [
"relative",
"<relative-path>"
],
"<asset3>": [
"system",
"<system-path>"
],
"<asset4>": [
"process",
],
"<asset5>": [
"executable",
],
}
})
library;
```
There are 5 asset path types. Symbols resolved in these asset types are
resolved as follows.
A. Absolute paths are dlopened, after which the symbol is looked up.
B. Relative paths are resolved relative to `Platform.script.uri`, and
dlopened, after which the symbol is looked up.
C. System paths are treated as absolute paths. (But we might explicitly
try to use `PATH` in the future.)
D. Symbols looked up in Process assets are looked up in the current
process.
E. Symbols looked up in Executable assets are looked up in the current
executable.
The native assets mapping can be provided in three ways.
X. In the invocation to `gen_kernel` with the `--native-assets`
argument. This uses the gen_kernel entry point for compiling
kernel.
Y. By placing a `native_assets.yaml` next to the
`package_config.json` used by the isolate group. This works for
`dart <source file>` and `Isolate.spawnUri(<dart source file>)`.
This uses the kernel_service entry point for compiling kernel.
Z. By sending a String containing the native assets mapping when
invoking the kernel_service directly from within the VM. Currently,
only used for unit tests.
TEST=tests/ffi/native_assets/asset_*_test.dart (X)
TEST=tests/ffi/native_assets/infer_native_assets_yaml_*.dart (Y)
TEST=runtime/vm/ffi/native_assets_test.cc (Z)
The library is synthesized from yaml in pkg:vm as AST.
Design doc: go/dart-native-assets
Bug: https://github.com/dart-lang/sdk/issues/49803
Change-Id: I8bf7000bfcc03b362948efd3baf168838948e6b9
Cq-Include-Trybots: luci.dart.try:vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-nnbd-mac-debug-arm64-try,vm-kernel-nnbd-mac-debug-x64-try,vm-kernel-win-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-kernel-precomp-win-debug-x64c-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-precomp-nnbd-linux-debug-x64-try,vm-kernel-precomp-win-debug-x64c-try,vm-kernel-precomp-nnbd-mac-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/264842
Reviewed-by: Martin Kustermann <kustermann@google.com>
- Flip flag to make strong null safety the default
- Remove code that auto detects null safety mode from source files,
it is necessary to specify --no-strong-null-safety to opt out.
- Retains sniffing of AOT/JIT snapshots and kernel files to determine
null safety mode, the opt out has to be done when generating these
file.
TEST=ci
Change-Id: If2c9608eedb7c46d9c3cd85e261ee9640e0d28eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261140
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Use `hasScheme` in place of comparing against the empty string, and
`isScheme` to compare against all other schemes.
TEST=No behavior changes.
Change-Id: Ifc9fd13c6cf37933ebd4a754c4b500dedbcb291b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231185
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
This change adds --source option to kernel compilers (front-end server
and gen_kernel). This option instructs compiler to include extra source
files into compilation even if they are not referenced from main
library.
TEST=Added test cases to pkg/frontend_server/test/frontend_server_test.dart
and pkg/vm/test/kernel_front_end_test.dart
Fixes https://github.com/dart-lang/sdk/issues/48144
Change-Id: If3d71538751e9ccfa8c82a5685d810cf811e021c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231334
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
There are 2 AOT-specific unit tests which rely on disabled
--use_table_dispatch flag. That flag is enabled everywhere and was
only disabled for the vm unit tests.
These 2 tests are now migrated to the new IL tests infrastructure
and --use_table_dispatch flag is enabled in the vm unit tests.
In order to support testing of IL of closures, IL test infra is
extended with pragma
@pragma('vm:testing:match-inner-flow-graph', 'inner name')
TEST=vm/dart/typed_data_aot_not_inlining_il_test
TEST=vm/dart/typed_data_aot_regress43534_il_test
Change-Id: I900e96136ddedb408ffca05d0c71893c3e12c2c4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/225325
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
* Add Canonicalize pass after CSE to erase graph differences between
64-bit and 32-bit platforms. These differences originate from different
treatment of integers (we unbox more eagerly on 64-bit platform) and
consequently affect load forwarding - which generates some redundant[1]
phis on 64-bit platform, but not on 32-bit platform. Adding this pass
also addresses other cases of unpredictable performance when IL changes
can cause CSE not to trigger a Canonicalize inside itself and regress
performance, by inhibiting subsequent optimizations.
* Allow IL tests to check whether the graph was compiled in sound
null safety mode or not - because graphs can have minor differences.
* Use `"$i"` instead of `i.toString()` in the test to allow TFA to
infer non-nullability of fields in non-sound-nullsafety mode.
[1] The definition of redundant phi differs between canonicalization
pass and load forwarding pass. The former unwraps redefinitions and
the latter does not. We are going to address this difference in a
more systematic way when we split input dependencies from control
dependencies.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-simarm_x64-try
Change-Id: Ifbd68fbb7f3b374ecee8ada1b3a4a2249139a108
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/220541
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
* Add support for dumping flow graphs in JSON (to make it machine
readable);
* Add support for controlling which functions are dumped through
a pragma annotation:
`@pragma('vm:testing:print-flow-graph'[, "passes filter"])`
* Replace simple matching DSL with programmatic matching
* Support obfuscated builds
Fixes https://github.com/dart-lang/sdk/issues/47340
TEST=vm/dart{,_2}/aot_prefer_equality_comparison_il_test
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try
Change-Id: Ie067ba451d311e6019a8c3a88c012231b0c50eb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/219240
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Our current unit testing infrastructure does not make it possible to
test AOT compilation pipeline end-to-end, because it does not run TFA
when generating Kernel.
This makes it challenging to write regression tests for certain issues.
Instead we extend test runner with a capability to perform IL matching
when running AOT tests.
runtime/docs/infa/il_tests.md provides details on how to write such tests.
TEST=manually
Change-Id: I6f5220b814f4a5d8c053efacd3711df495dea404
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214961
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@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>
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>
As part of implementing hot-reload for isolate groups, we have to ensure
reloads on a group are performed using the same state of incremental
compiler.
This means we cannot use a specific isolate's information (such as it's
main port) for reloading purposes. Instead we use the unqiue isolate
group id when communicating with the kernel service.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Existing test coverage, future test when hot-reload is fully
implemented with isolate groups.
Change-Id: Ifab39cd2ba689c08507dfab4091cd26951ed54e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185320
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@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>
This adds a new messages kind 'info' to the CFE for showing general
information during compilation. A 'configuration' options is added
to `CompilerOptions` for telling the CFE how it is run.
The configuration 'compile' is added for when the CFE is invoked to
produces an "executable" as when running `dart compile`. When
configuration is set, the CFE emits an info message about the
null safety compilation mode.
Support for `dart compile exe` and `dart compile js` is added in this
CL. Support for `dart compile kernel|app-jit|aot` is not included.
In response to https://github.com/dart-lang/sdk/issues/44234
TEST=pkg/dartdev/test/commands/compile_test.dart
Change-Id: I08f51e2a3f5ad4841c4d703bcd266b7afb63c7c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178982
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Emphasize that the operation is going away,
and mark constructor as deprecated.
TEST= Refactoring+deprecation only, covered by existing tests.
Change-Id: I82aa044cd2cf7bf347b624371399f44bda8f4a07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173261
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Vyacheslav Egorov