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)
* Provide flutter sdk kernel files to dwds launcher instead of dart ones
* Update log test to report all warnings
* Update licences for new files
* Addressed CR comments
* Addressed CR comments
