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
Cleans up header order/grouping for consistency: associated header, C/C++ system/standard library headers, library headers, platform-specific #includes.
Adds <cstring> where strlen, memcpy are being used: there are a bunch of places we use them transitively.
Applies linter-required cleanups. Disables linter on one file due to included RapidJson header. See https://github.com/flutter/flutter/issues/65676
This patch does not cover flutter/shell/platform/darwin. There's a separate, slightly more intensive cleanup for those in progress.
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
Reland #19396 with a fix for improper scale that was affecting internal tests
Tested: Ran all unittests, ran internal tests, and ran workstation on Fuchsia
BUG: 53062, 53063
The fuchsia code around metrics and sizing was just sending this
information through a side-channel, when the engine already had the
information available. So, delete all of it to make future CLs simpler.
Additionally, the SceneUpdateContext has many unneccesary dependencies
re: metrics and PaintTasks. Break those to make future CLs simpler.
Tested: Ran all unittests and ran workstation on Fuchsia
BUG: 53062, 53063
This allows Fuchsia components executed by the Flutter runner to
specify a directory containing assets if they wish to store assets
separate from program data. This is specified in the program metadata
field within the component's specification with the new "assets"
attribute. If this attribute is absent, assets are loaded relative to
the path specified in the "data" attribute as before.
This is useful in the short term to use a location in the package where
we can store small files more efficiently. It is also potentially
useful longer term to enforce a stronger separatation between
executable program data and non-executable assets.
This commit adds some basic unit testing for the data parsing to the
flutter_runner_tests suite.
In order to better support different products on Fuchsia, we should
change performance-sensitive attributes based on config files passed in.
This change does so for `vsync_offset`.
On Fuchsia, we can now get executable VMOs from trusted backing
filesystems. This allows us to remove the use of replace_as_executable
in favor of opening files with `fdio_open_fd_at` with the
`OPEN_RIGHT_EXECUTABLE` flag and getting VMOs by calling
`fdio_get_vmo_exec`.
By moving the responsibility for executability into the filesystem, we
are able to remove `deprecated-ambient-replace-as-executable` from
component manifests for non-JIT runners (the JIT runners still call
replace_as_executable in Dart's allocator). It wasn't abundantly clear
whether .cmx files for tests were used purely in AOT runtime
environments or also saw JIT usage, so I left those as-is.
For context: this is a second attempt at #16690, which was reverted
because it broke the Dart JIT runner. The primary difference is that
this time around, we correctly handle absolute vs relative paths,
depending on whether library loading bottoms out in `fdio_open_fd` or
`fdio_open_fd_at`. I've added additional assertions to help ensure any
new usages use the correct shape of path.
Testing: I verified locally that the flutter product runner works on
Astro, and also successfully ran the Dart JIT example test (which was
the thing blocking the google3 roll with the previous attempt at this
patchset).
Co-authored-by: Drew Fisher <zarvox@google.com>
On Fuchsia, we can now get executable VMOs from trusted backing
filesystems. This allows us to remove the use of replace_as_executable
in favor of opening files with `fdio_open_fd_at` with the
`OPEN_RIGHT_EXECUTABLE` flag and getting VMOs by calling
`fdio_get_vmo_exec`.
By moving the responsibility for executability into the filesystem, we
should be able to remove deprecated-ambient-replace-as-executable from
component manifests for non-JIT runners (the JIT runners still call
replace_as_executable in Dart's allocator).
Test: verified locally that this works on Astro on a _user build with
the runtime allowlist tightened.
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
The bug in the original CL was that we were not running replace_as_executable in OpenVmo if the namespace was not provided.
This was a divergence in behavior for MappedResource::LoadFromNamespace compared to the current implementation.
This reverts commit 4312d37eb1cdd0ed2e7b44647c7156499b741ac7.
Once https://fuchsia-review.googlesource.com/c/topaz/+/351729 lands, the
diagnostics directory will be present, this would be safe to do and the
roller won't be blocked again.
Since Flutter tracing is wired up to Fuchsia system level tracing (and
that includes Skia tracing within Flutter), it makes more sense to
enable Skia tracing by default on Fuchsia, and to control Flutter Skia
tracing, rely on whether Fuchsia system tracing is enabled, in progress,
and contains the "skia" category.
* [flutter_runner] Make rd and rx uniform
Currently we pass paths for readonly files and pass
in fds for rx. Now passing in fds everywhere.
* pass full paths
- Don't use 'unhandled' as that implies fatality which this is not
- Don't mention shutdown because this is not necessarily an exception-after-shutdown issue
Follow-up issue filed https://github.com/flutter/flutter/issues/41506 to implement the unit test for this.
Explicitly set |Application|'s |flutter::Settings| |trace_skia| field to
false (it currently defaults to false), in order to slightly simplify
the enabling skia trace events workflow.
PT-145 #comment-patch
Change-Id: Ib40f9ed3dc6f824056465db2cd45309c78b7e3b4
Build rules still reference creating share snapshot data and instructions. This makes the engine to always pass them as empty to the dart vm. To be followed up with a change to alter the build rules to stop referencing the shared snapshots.
This is not being used currently and the fact that the runner will be built outside of the flutter tree means that the apps will not have much to gain via shared snapshots. The rationale behind this change is to partially make migrating the runner out of topaz tree easier.
Change-Id: Ibc4dd6a298d65082416af753522f5a17c88a750a
