Passing the --causal-async-stacks flag to the VM will cause it to error
on VM startup. The VM will remove the flag entirely, but before doing so
we'll have to remove usages of the negated version of the flag, namely
--no-causal-async-stacks.
Used the the `misspell` tool available at
https://github.com/client9/misspell, then applied hand-corrections. It's
possible we could adopt this as a presubmit, but there are still enough
false positives that it may not be worth the effort.
Snapshots compiled with sound null-safety enabled require changes to the way in
which isolates are launched. Specifically, the `Dart_IsolateFlags::null_safety`
field needs to be known upfront. The value of this field can only be determined
once the kernel snapshot is available. This poses a problem in the engine
because the engine used to launch the isolate at shell initialization and only
need the kernel mappings later at isolate launch (when transitioning the root
isolate to the `DartIsolate::Phase::Running` phase). This patch delays launch of
the isolate on the UI task runner till a kernel mapping is available. The side
effects of this delay (callers no longer having access to the non-running
isolate handle) have been addressed in this patch. The DartIsolate API has also
been amended to hide the method that could return a non-running isolate to the
caller. Instead, it has been replaced with a method that requires a valid
isolate configuration that returns a running root isolate. The isolate will be
launched by asking the isolate configuration for its null-safety
characteristics.
A side effect of enabling null-safety is that Dart APIs that work with legacy
types will now terminate the process if used with an isolate that has sound
null-safety enabled. These APIs may no longer be used in the engine. This
primarily affects the Dart Convertors in Tonic that convert certain C++ objects
into the Dart counterparts. All known Dart Converters have been updated to
convert C++ objects to non-nullable Dart types inferred using type traits of the
corresponding C++ object. The few spots in the engine that used the old Dart
APIs directly have been manually updated. To ensure that no usage of the legacy
APIs remain in the engine (as these would cause runtime process terminations),
the legacy APIs were prefixed with the `DART_LEGACY_API` macro and the macro
defined to `[[deprecated]]` in all engine translation units. While the engine
now primarily works with non-nullable Dart types, callers can still use
`Dart_TypeToNonNullableType` to acquire nullable types for use directly or with
Tonic. One use case that is not addressed with the Tonic Dart Convertors is the
creation of non-nullable lists of nullable types. This hasn’t come up so far in
the engine.
A minor related change is reworking tonic to define a single library target.
This allows the various tonic subsystems to depend on one another. Primarily,
this is used to make the Dart convertors use the logging utilities. This now
allows errors to be more descriptive as the presence of error handles is caught
(and logged) earlier.
Fixes https://github.com/flutter/flutter/issues/59879
Lazy async stacks were already enabled by-default in AOT mode in [0] - which made the
gen_snapshot invocations use "--lazy-async-stacks --no-causal-async-stacks".
This change does the same with the engine defaults, which makes this be enabled
by-default in JIT mode as well.
See go/dart-10x-faster-async for more information.
This is a re-land: A fix for what we believe to have caused the last revert has landed upstream in Dart in dart-lang/sdk@0004589
[0] flutter/flutter@3478232
This was already enabled by-default in AOT mode in [0] - which made the
gen_snapshot invocations use "--lazy-async-stacks --no-causal-async-stacks".
See go/dart-10x-faster-async for more information.
[0] https://github.com/flutter/flutter/commit/347823234fd
This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.
In generated text fixture location lookup code:
When the second argument to write_file() is a list, it is written one
item per line to the path specified by the first argument. This ensures
that we emit a trailing newline at EOF to comply with -Wnewline-eof.
Elsewhere:
Lack of a newline at EOF was undefined behaviour prior to C++11. The
Fuchsia tree sets -Wnewline-eof in its buildroot, so we plan to do the
same. This cleans up remaining first-party C++ sources that don't
include a trailing newline.
* Allow specifying both Dart and non-Dart fixtures in engine unittests.
This fixes numerous issues in the way in which fixtures were managed
in the engine unit-tests.
* Instead of only being able to specify Dart fixtures, unit-tests may specify
non-Dart fixtures as well. These are simply copied over to the fixtures
directory known to the unit-test at runtime.
* An issue where numerous Dart files could be given to the kernel snapshotter
has been addressed. It was anticipated that such a (legal) invocation to the
kernel snapshotter would produce a snapshot with the contents of all the Dart
files added to the root library. This is incorrect and the behavior in this
case is undefined.
* Dart files referenced by the main Dart file are correctly tracked via a
depfile.
* The snapshotter arguments have been cleaned up to get rid of unused
arguments (`—strong`) and the use of the VM product mode argument has been
corrected to no longer depend on the Flutter product mode.
As of the migration to Dart 2, it has been necessary to compile Dart to
kernel prior to execution. The embedder currently requires that the
resulting kernel file be named `kernel_blob.bin` and be located at the
root of the assets directory passed to the embedder API.
This patch updates the test_fixtures build rule to perform a kernel
compile using frontend_server, outputting `kernel_blob.bin` to
`fixtures/test_target_name` directory, and updates the embedder
unittests to specify the kernel file rather than the Dart source file.
Since the kernel compiler requires a `main()` function to be defined, it
also updates `simple_main.dart` from runtime_unittests to define
`main()` rather than `simple_main()`.
This also updates all existing sub-targets to be testonly.
This relands commit 4e4fb4608da95d198b0e796478462285ab974a3c, which was
reverted in commit 566db0ecb8f293bb9f7ff1fc39076b08336e0148. Rather than
running as prebuilt_dart_action, we use dart_action to ensure the
frontend snapshot it compatible with the VM on which it's executed.
This reverts commit 4e4fb4608da95d198b0e796478462285ab974a3c.
This broke dynamic release mode builds of
//flutter/runtime:runtime_fixtures_kernel (likely all product-mode
builds).
Compile embedder unit test Dart to kernel
As of the migration to Dart 2, it has been necessary to compile Dart to
kernel prior to execution. The embedder currently requires that the
resulting kernel file be named `kernel_blob.bin` and be located at the
root of the assets directory passed to the embedder API.
This patch updates the test_fixtures build rule to perform a kernel
compile using frontend_server, outputting `kernel_blob.bin` to
`fixtures/test_target_name` directory, and updates the embedder
unittests to specify the kernel file rather than the Dart source file.
Since the kernel compiler requires a `main()` function to be defined, it
also updates `simple_main.dart` from runtime_unittests to define
`main()` rather than `simple_main()`.
This also updates all existing sub-targets to be testonly.
