Currently CMake is tested entirely through `build_linux_test.dart`. However, CMake is also used for Windows builds. This adds additional "generic" tests:
1. Parsing CMake files
2. Generating CMake config files.
In the future, this will be used to test that generated CMake config files contain the expected version information, which will be used to flow version information to Windows executables.
Part of https://github.com/flutter/flutter/issues/73652.
This PR adds extra timings for a hot reload.
As an example, before a user might see
> Performing hot reload...
> Reloaded 1 of 788 libraries in 554ms.
With this PR it would instead be something like
> Performing hot reload...
> Reloaded 1 of 788 libraries in 554ms (compile: 33 ms, reload: 153 ms, reassemble: 310 ms).
In https://github.com/flutter/flutter/pull/103771, we rolled
dependencies in Flutter, which triggered an update of package:coverage
to v1.3.1. The new version includes
https://github.com/dart-lang/coverage/pull/370 in which two deprecations
landed:
* The `Resolver` default constructor was deprecated and replaced with
the `Resolver.create` static factory method, which unfortunately
happens to be async.
* The `packagesPath` parameter to `HitMap.parseJson`, which takes the
path to the `.packages` file of the package for which coverage is to
be collected, was deprecated. This parameter was replaced with
`packagePath` in https://github.com/dart-lang/coverage/pull/370 which
was part of the overall deprecation of the .packages file in Dart
itself https://github.com/dart-lang/sdk/issues/48272. The overall goal
being that end-user code shouldn't need to know about implementation
details such as whether dependency information is stored in a
.packages file or a package_info.json file, but rather use the
package_config package to obtain the package metadata and perform
other functions such as resolving its dependencies to filesystem
paths. packagesPath was replaced by packagePath, which takes the path
to the package directory itself. Internally, package:coverage then
uses package_config to do the rest of the package/script URI
resolution to filesystem paths.
This migrates off the deprecated `packagesPath` parameter to the
replacement `packagePath` paramter.
Issue: https://github.com/flutter/flutter/issues/103830
* Fix issues running integration tests through DAP
These adapters were incorrectly trying to connect a DDS instance even when Flutter would create its own. This change disables DDS in the DAP layer and leaves it to Flutter (although it passes `--no-dds` on to Flutter if provided to the DAP process).
Also fixes an issue where we would unnecessarily connect the VM Service for tests even in 'noDebug' mode because of a change/fix that now includes a 'vmServiceUri' in the `test.startedProcess` event.
Flutter uses `vswhere.exe` to find Visual Studio installations and determine if they satisfy Flutter's requirements. However, `vswhere.exe`'s JSON output is known to contain bad UTF-8. This change ignores bad UTF-8 as long as they affect JSON properties that are either unused, or, used only for display purposes by Flutter.
Fixes: https://github.com/flutter/flutter/issues/102451
`VisualStudio` calls `vswhere.exe` to find Visual Studio installations and determine if they satisfy Flutter's requirements. Previously, `VisualStudio` stored the JSON output from `vswhere.exe` as `Map`s, resulting in duplicated logic to read the JSON output (once to validate values, second to expose values). Also, `VisualStudio` stored two copies of the JSON output (the latest valid installation as well as the latest VS installation).
This change simplifies `VisualStudio` by introducing a new `VswhereDetails`. This type contains the logic to read `vswhere.exe`'s JSON output, and, understand whether an installation is usable by Flutter. In the future, this `VswhereDetails` type will be used to make Flutter doctor resilient to bad UTF-8 output from `vswhere.exe`.
Part of https://github.com/flutter/flutter/issues/102451.
* Use libraryFilters flag to speed up coverage collection
* Allow libraryNames to be null
* Unconditionally enable the reportLines flag
* Fix analysis errors
Roll dependendencies
This rolls depdendencies to latest using
flutter update-packages --force-upgrade
This change includes three code changes:
* Removes charcode from the dependencies allowlist since it no longer
appears in the transitive closure of dependencies of the flutter,
flutter_test, flutter_driver, flutter_localizations, and
integration_test packages.
* Uses Resolver.create instead of the deprecated Resolver constructor.
The default Resolver constructor has been deprecated in favour of the
static Resolver.create() factory function, which unfortunately happens
to be async. Propagated the async-ness up the chain.
This change was partially reverted and the deprecation ignored in this
patch until package:coverage can be rolled internally at Google.
* Eliminates the use of the deprecated packagesPath parameter to
HitMap.parseJson. This parameter was deprecated and replaced with
packagePath in https://github.com/dart-lang/coverage/pull/370 which
was part of the overall deprecation of the .packages file in Dart
itself https://github.com/dart-lang/sdk/issues/48272. The overall goal
being that end-user code shouldn't need to know about implementation
details such as whether dependency information is stored in a
.packages file or a package_info.json file, but rather use the
package_config package to obtain the package metadata and perform
other functions such as resolving its dependencies to filesystem
paths. packagesPath was replaced by packagePath, which takes the path
to the package directory itself. Internally, package:coverage then
uses package_config to do the rest of the package/script URI
resolution to filesystem paths.
This change was partially reverted and the deprecation ignored in this
patch until package:coverage can be rolled internally at Google.
This is a pre-update prior to updating flutter_template_images in
https://github.com/flutter/flutter/pull/103739
Issue: https://github.com/flutter/flutter/issues/103371
Issue: https://github.com/flutter/flutter/issues/103775
Issue: https://github.com/flutter/flutter/issues/103830
When re-applying the partially-reverted changes to code coverage,
we'll need to patch host_entrypoint.dart internally to await the Future
that we'll be returning rather than a non-async value.
