Use Python backslashreplace
to avoid UNRESOLVED tests
#4366
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 #4308.
Followup to #2145, which added a two-step process for decoding compiler and test output. See Python's Unicode documentation and
bytes.decode
documentation. OurdecodeOutput(bytes)
first triesbytes.decode()
, i.e.bytes.decode(encoding='utf-8', errors='strict')
, to handle EDG's UTF-8 output.'strict'
asks it to throw aUnicodeDecodeError
(derived fromUnicodeError
). If that happens, we assume we're looking at MSVC's output in the active codepage, so we fall back to locale-aware decoding.The problem was that this fallback was still
'strict'
, so if the test emitted unrecognized characters, we'd get anotherUnicodeDecodeError
, this time uncaught. That causes the test to be reported as UNRESOLVED. It originally had incredibly confusing output, which #4323 improved by printing the contents of theUnicodeDecodeError
.How can we get a test printing unrecognized characters? I validated my fix with a deterministic
puts("\x8d");
. (I don't think it's worth adding a test to validate this part of the test harness.) We originally encountered it sporadically, due to heap corruption tracked by #4268. Due to an STL bug, those tests reliably corrupt the heap, but (due to a still-mysterious chain of events), as the UCRT attempts to print its "HEAP CORRUPTION DETECTED" message, when printing the block type (usually "Normal"), something is damaged and it occasionally prints garbage memory contents. (We did corrupt the heap, after all.)By requesting
'backslashreplace'
during the fallback conversion, we avoid uncaught exceptions here. This will allow the test to pass (if it simply happened to print bizarre characters during its execution) or fail (if it printed bizarre characters during its plunge into Mount Doom), with readable output captured in the logs thanks to the backslash escaping.I considered also marking #4268's heap-corrupting tests as SKIPPED instead of FAIL. However, they do seem to be reliably failing with detected heap corruption, the only sporadic part was whether they corrupted the heap badly enough to damage the UCRT's message. Unless and until we start seeing sporadic "unexpected passes" here, I am inclined to leave them marked as FAIL. Thus #4308 will be truly fixed as we'll no longer encounter sporadic test run failures due to UNRESOLVED (the affected tests will FAIL but that's expected, so the test run as a whole will pass).