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).
* 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
