Repository navigation
[tool] Accept plutil diagnostics from stderr in plist_parser_test (macOS 26) - #193292
Merged
auto-submit[bot] merged 2 commits intoSep 24, 2026
Merged
auto-submit[bot] merged 2 commits into
auto-submit[bot] merged 2 commits into
Conversation
On macOS 26, plutil writes its parse diagnostic to stderr instead of stdout, so the two malformed-plist tests found the message in logger.errorText rather than logger.statusText and failed. Check both streams and assert errorText endsWith the ProcessException block so the prepended diagnostic is tolerated. Test-only; PlistParser is unchanged. Fixes flutter#193159
github-actions
Bot
added
the
tool
On macOS 26 plutil moved its parse diagnostic from stdout to stderr, but the wording is unchanged. Assert the full diagnostic against the combined status and error logs instead of two fragments, so the tests still catch a change in the reported error. Also scope the comments to what was observed (before macOS 26 vs macOS 26).
okorohelijah
marked this pull request as ready for review
September 24, 2026 19:23
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates plist_parser_test.dart to handle diagnostic output changes introduced in macOS 26, where plutil writes parse diagnostics to stderr instead of stdout. The tests now combine logger.statusText and logger.errorText for diagnostic assertions and use endsWith for error log matching. There are no review comments, and I have no feedback to provide.
vashworth
approved these changes
Sep 24, 2026
vashworth
added
autosubmit
flutter-dashboard
Bot
removed
the
autosubmit
This was referenced Sep 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #193159
What's failing
Two tests in
plist_parser_test.dartfail on macOS 26 (first seen onstaging.shadow/Mac tool_integration_tests_1at Mac-26.6.2 / Xcode 17C52,https://ci.chromium.org/b/8670252478857878881):
PlistParser.getValueFromFile<String> returns null for a malformed plist filePlistParser.replaceKey returns false for a malformed plist fileBoth tests still get the right result (
null/false, andplutilstillexits 1). What changed is where
plutilprints its error:plutilprinted<path>: Property List error: … / JSON error: …on stdout.
plutilwas rewritten (Apple open-sourced the new version inswift-corelibs-foundation,
Sources/plutil/PLUContext.swift) and the samemessage now goes to stderr.
ProcessUtils.runSynclogs a failed command's stdout withprintStatusandits stderr with
printError. So on macOS 26logger.statusTextis empty andthe diagnostic shows up in
logger.errorTextinstead, ahead of theProcessException:line. The tests only looked atstatusText.#172913 ran into the same plutil change last year in
xcode_backend.dart.The fix
Test-only change.
PlistParseritself is fine.statusText + errorTextrather thanstatusTextalone, so the test passes whichever stream plutil uses. Thefull message is still asserted, so a change in the wording would still be
caught.
errorTextends with theProcessExceptionblock instead ofequalling it, since on macOS 26 the plutil message now comes first.
How I verified it
Mac tool_integration_tests_1(subshard1_10, the one thatcontains
plist_parser_test.dart) on a Mac-26.6.2 bot (mac-340-g140,the same bot as the original failure) at this PR's head:
https://ci.chromium.org/b/8669753954317678657 — green, both tests pass.
Pre-launch Checklist
///).