ci(freebsd-amd64): accept 'unresolved reference to' wording in etext/end XFAIL matcher - #84
Merged
GGRei merged 1 commit intoJul 31, 2026
Conversation
…atcher Run 30421217468 is a matcher false negative, not a real regression: this branch's tcc now reports "tcc: error: unresolved reference to 'etext'"/ "'end'" instead of the "undefined symbol '...'" wording is_known_etext_end() originally matched - same known linker bug (tcc's FreeBSD backend never defines the plain BSD-style etext/end BDWGC references), different tcc diagnostic wording. Accept both wordings rather than replacing one with the other, so a differently-built tcc.exe landing here later isn't a second false negative. Workflow-only change: no binary rebuild, no publication, and every existing guard is untouched - exit-code rejection (reject exit 0 and signal-terminated exits >128), the exclusivity check (any OTHER tcc error line still fails the job for real), and the outer aggregate-shape match are all unmodified, just extended to recognize the second wording. The real upstream tcc fix (da58264) isn't shipped in any binary on this branch yet and will be validated separately on native FreeBSD - this lane is still expected to XFAIL the same way after this change, just correctly recognized as the known case instead of hard-failing as unexpected. Co-Authored-By: WOZCODE <contact@withwoz.com>
Author
|
Is ready for merge @GGRei |
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
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
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.
Summary
Run 30421217468 is a matcher false negative, not a real regression: this branch's
tcc.exenow reportstcc: error: unresolved reference to 'etext'/'end'instead of theundefined symbol '...'wordingis_known_etext_end()originally matched. Confirmed directly from that run's log:Same known linker bug (tcc's FreeBSD backend never defines the plain BSD-style
etext/endthat BDWGC references directly - see the step's own root-cause comment above it), just a different tcc diagnostic wording. Fixed by accepting both wordings rather than replacing one with the other, so a differently-builttcc.exelanding here later isn't a second false negative.Workflow-only change - no binary rebuild, no publication. Every existing guard is untouched:
0and signal-terminated exits>128)PASS crash,FAIL gc_alloc/hello (compile error))The real upstream tcc fix (
da58264) isn't shipped in any binary on this branch yet and will be validated separately on native FreeBSD - this lane is still expected to XFAIL the same way after this PR, just correctly recognized as the known case instead of hard-failing as unexpected.Test plan
yaml.safe_load) and the modified step's shell syntax-checked (bash -n).is_known_etext_end()extracted and run standalone against the exact captured error text from run 30421217468 - now correctly recognized as the known XFAIL.undefined symbolwording still matches (backward compatible), an unrelated error text is still correctly rejected, and exit code0is still correctly rejected.