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
* e0f736dab Set error handler (flutter/engine#33402)
* dcd596a99 Roll Dart SDK from 381855557df2 to f3bf9025c141 (1 revision) (flutter/engine#33411)
* 5c2a16e07 Roll Fuchsia Linux SDK from F0_B8WVKY... to IZ7_b83xC... (flutter/engine#33415)
* 4958a245a Roll dart sdk to 1bdb83bddf96c41cc046810c697a2c80bfaaaf19 (flutter/engine#33416)
* d2fd3d852 Roll Fuchsia Mac SDK from t_ky8l6nb... to egBfZMmTP... (flutter/engine#33417)
* d58fc83f1 Roll Dart SDK from 1bdb83bddf96 to 0bc104c3e959 (1 revision) (flutter/engine#33419)
* 8ab172029 Roll Skia from 0a5146ca3ffd to 16fa353926b8 (28 revisions) (flutter/engine#33420)
* Remove fraction translation
* Update codesign.dart
Co-authored-by: Jonah Williams <jonahwilliams@google.com>
`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)
This adds a simple VoidCallbackAction and VoidCallbackIntent that allows configuring an intent that will invoke a void callback when the intent is sent to the action subsystem. This allows binding a shortcut directly to a void callback in a Shortcuts widget.
I also added an instance of VoidCallbackAction to the default actions so that simply binding a shortcut to a VoidCallbackIntent works anywhere in the app, and you don't need to add a VoidCallbackAction at the top of your app to make it work.
