This change adds a FlutterMetalRendererConfig that lets embedders
specify metal as rendering api.
Also adds a test that validates rendering a gradient using metal.
Changes to make this work:
- Had to change the use of an UBool constant `FALSE` to 0 because
the file referring to it does not include the respective header.
- Had to change the license checker to ignore files in the directory
icu/source/samples. There were random changes to the licensing
headers which tripped up license checks. And since we don't include
samples in the binaries we build, the most efficient way to fix it is
to exclude sample code from license checks.
Issue: https://github.com/flutter/flutter/issues/70370
Adds a package config file to the const finder test fixtures to unblock the null safety flag removal change.
Otherwise these fixtures get opted in to null safety and some constants are missing (presumably because they are invalid).
Related dart-lang/sdk#43872
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
* setting an env variable using commit no
* change variable name
* try to use ref no as string
* use echo for output
* remove all the other stdout
* echo json instead of only the commit no
* use the file method
* list the directory contents
* remove pwd. print flutter version verbose
* cloning flutter repo for luci recipes
* rename the file, script does not clone the repo, but reset it to the right commit
* adding the version logging
* [gn] Adds a flag to turn off git hash versioning
Without this flag, it is excessively tedious to build Dart SDK
for local testing on Fuchsia, since Fuchsia runner will reject
a Dart SDK without a matching version.
* [gn] Add flag --no-dart-version-git-info
This flag suppresses the SDK stamping by git hash, which allows
deploying self-built Dart SDK. Without this flag, it is impossible
to build and deploy a development Dart SDK on Fuchsia.
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.
Add copyright headers in a few files where they were missing.
Trim trailing blank comment line where present, for consistency with
other engine code.
Use the standard libtxt copyright header in one file where it differed
(extra (C) and comma compared to other files in libtxt).
This also amends tools/const_finder/test/const_finder_test.dart to look
for a const an additional four lines down to account for the copyright
header added to the test fixture.
a custom version string of Dart for Flutter.
Dart is going to be removing support for this ability to generate
a custom version string (only dev branch hashes are being rolled into
flutter).
This reverts commit 5570bdf6b5eacc03296e2cf50c033810d8ff6d6d.
The LUCI recipe issue should have already been fixed by @christopherfujino
Try to trigger the LUCI tests with this as the "retry" button is somehow disabled for https://ci.chromium.org/p/flutter/builders/prod/Linux%20Fuchsia/4755 even if I logged in.
- Rolls buildroot to pick up
https://github.com/flutter/buildroot/pull/389
- Adds support to the gn wrapper for setting the traget CPU on Windows
Attempting to generate Windows arm64 GN files will currently fail, due
to lack of arm64 support for an OpenGL test support target, but this
sets the foundation, and makes experimentation easier.
Part of https://github.com/flutter/flutter/issues/62597
