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
Adds a bit more clarifying documentation to the implementation of the
outputFollowsExit case, and adds tests that verify the behaviour of
stderr, stdout of processes launched via FakeProcessManager.
Specifically:
* Verifies that stderr, stdout are not emitted immediately after process
exit if outputFollowsExit is true. They must be emitted at least one
turn through the event loop later.
* Verifies that ProcessResult.stderr, stdout have the type documented
according to the encoding passted to Process.run/runSync:
* List<int> if null is passed as the encoding.
* String (in the default system encoding) if no encoding is specified.
* String (in the specified encoding) if an encoding is specified.
This is additional testing relating to refactoring landed in:
https://github.com/flutter/flutter/pull/103947
Issue: 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
Because this class has some subtle behaviour with regards to control of
exit timing and when and how it streams data to stderr and stdout, it's
worth adding unit tests for this class directly, as well as (in a
followup patch) for FakeProcessManager.
This is additional testing relating to refactoring landed in:
https://github.com/flutter/flutter/pull/103947
Issue: https://github.com/flutter/flutter/issues/102451
`FakeProcessManager` is a test-oriented implementation of `ProcessManager`
that simulates launching processes and returning `ProcessResult` objects
whose `exitCode`, `stdout`, `stderr` can be used to write platform-portable,
hermetic tests that don't rely on actually launching processes from
executables on disk. Its `run` and `runSync` methods provide asynchronous and
synchronous variants of this functionality.
Previously, the behaviour of `run` and `runSync` were inconsistent with
regards to the treatment of the `stdoutEncoding` (similarly,
`stderrEncoding`) parameters:
`run`:
* if the encoding was null, `ProcessResult.stdout` was returned as a
String in UTF-8 encoding. This was incorrect. The behaviour as
specified in `ProcessResult.stdout` is that in this case, a raw
`List<int>` should be returned.
* If the encoding was unspecified, `ProcessResult.stdout` was returned as
a `String` in the `io.systemEncoding` encoding. This was correct.
* If the encoding was non-null, `ProcessResult.stdout` was returned as a
`String` in the specified encoding. This was correct.
`runSync`:
* if the encoding was null, `ProcessResult.stdout` was returned as a
`List<int>` in UTF-8 encoding. This was incorrect. The behaviour as
specified in `ProcessResult.stdout` is that in this case, a raw
`List<int>` should be returned.
* If the encoding was unspecified, `ProcessResult.stdout` was returned as
`List<int>` in UTF-8 encoding. This was incorrect. The behaviour as
specified in `ProcessResult.stdout` is that in this case, a String a
`String` in the `io.systemEncoding` encoding should be returned.
* if the encoding was non-null, `ProcessResult.stdout` was returned as a
`String` in unknown (but probably UTF-8) encoding. This was incorrect.
The behaviour as specified in `ProcessResult.stdout` is that in this
case, a `String` in the specified encoding should be returned.
`_FakeProcess`, from which we obtain the fake stdout and stderr values now
holds these fields as raw `List<int>` of bytes rather than as `String`s. It
is up to the user to supply values that can be decoded with the encoding
passed to `run`/`runAsync`.
`run` and `runAsync` have been updated to set stdout (likewise, stderr) as
specified in the `ProcessResult` documentation.
This is pre-factoring for #102451, in which the tool throws an exception
when processing the JSON output from stdout of the `vswhere.exe` tool,
whose output was found to include the `U+FFFD` Unicode replacement
character during UTF-8 decoding, which triggers a `toolExit` exception
when decoded using our [Utf8Decoder][decoder] configured with `reportErrors` =
true. Because `FakeProcessManager.runAsync` did not previously invoke
`utf8.decode` on its output (behaviour which differs from the non-fake
implementation), it was impossible to write tests to verify the fix.
Ref: https://api.flutter.dev/flutter/dart-io/ProcessResult/stdout.html
Issue: https://github.com/flutter/flutter/issues/102451
[decoder]: fd312f1ccf/packages/flutter_tools/lib/src/convert.dart (L51-L60)
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.
Point users of boolArgDeprecated to boolArg rather than to
boolArgDeprecated in order to avoid losing users to infinite loops or
stack overflows depending on their implementation.
