Make sure fmt-write-bloat doesn't vacuously pass on no symbols
#143669
+75
−11
Conversation
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
rustbot
added
A-run-make
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
rust-bors bot
added a commit
that referenced
this pull request
Jul 9, 2025
Make sure `fmt-write-bloat` doesn't vacuously pass on no symbols Previously, the test only checks for the absence of certain panic symbols, but having no symbols was also a possible albeit vacuous way to satisfy this assertion. Fix this by checking we at least observe the `main` symbol which is always expected to be present. Noticed in #142841 (comment). r? `@ChrisDenton` try-job: x86_64-msvc-*
This comment was marked as outdated.
This comment was marked as outdated.
|
Hm. Let me try this locally on windows. |
jieyouxu
added
S-waiting-on-author
|
The failure is not surprising to me. On Windows, symbols are not contained in the binary itself and are instead in a separate file (the .pdb). So the |
|
Oh of course... D'oh. Let me see if I can cook something up. |
This comment was marked as outdated.
This comment was marked as outdated.
jieyouxu
changed the title
fmt-write-bloat doesn't vacuously pass on no symbolsfmt-write-bloat doesn't vacuously pass on no symbols
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
rust-bors bot
added a commit
that referenced
this pull request
Jul 9, 2025
[WIP] Make sure `fmt-write-bloat` doesn't vacuously pass on no symbols Previously, the test only checks for the absence of certain panic symbols, but having no symbols was also a possible albeit vacuous way to satisfy this assertion. Fix this by checking we at least observe the `main` symbol which is always expected to be present. Noticed in #142841 (comment). r? `@ChrisDenton` try-job: aarch64-apple try-job: x86_64-apple-1 try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1
|
|
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
rust-bors bot
added a commit
that referenced
this pull request
Jul 9, 2025
[WIP] Make sure `fmt-write-bloat` doesn't vacuously pass on no symbols Previously, the test only checks for the absence of certain panic symbols, but having no symbols was also a possible albeit vacuous way to satisfy this assertion. Fix this by checking we at least observe the `main` symbol which is always expected to be present. Noticed in #142841 (comment). r? `@ChrisDenton` try-job: aarch64-apple try-job: x86_64-apple-1 try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1
bors
added
S-waiting-on-author
jieyouxu
force-pushed
the
fmt-write-bloat
branch
from
82d9758 to
a51fb59
Compare
This comment has been minimized.
This comment has been minimized.
jieyouxu
commented
Oct 18, 2025
Comment on lines
22
to
24
| // NOTE: against the GCC codegen backend, the assertion | ||
| // `object_contains_any_symbol_substring(&expect_panic_symbols, &panic_syms)` fails. | ||
| //@ ignore-backends: gcc |
There was a problem hiding this comment.
Remark: ignoring this test for GCC cg backend, I do not feel like investigating why #147819 (comment) when the GCC cg backend is used, we observe some of these panic symbols.
There was a problem hiding this comment.
Hm, ok that's fair. It feels like this should ideally work with gcc but that needn't be done now. I just hope this isn't a canary warning us the test is going to be flaky 😛.
There was a problem hiding this comment.
Yeah, if the test ends up becoming flaky, I honestly rather disable or even remove this entire test. Because this test is exercising panic-machinery related optimizations through indirect implementation details, and checking for what is there and isn't there are IMO equally prone to "no longer testing what it's supposed to test". This is still the case even if we use DIA wrappers :(
|
@rustbot review |
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=iffy (should be fine to rollup if need be though) |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Oct 18, 2025
Make sure `fmt-write-bloat` doesn't vacuously pass on no symbols This PR fixes the `tests/run-make/fmt-write-float/` run-make test to both (1) not vacuously pass on no symbols at all, and (2) compare panics symbols under optimizations versus no optimizations. ### Context Previously, the test only checks for the absence of certain panic symbols, but having no symbols was also a possible albeit vacuous way to satisfy this assertion. Noticed in #142841 (comment). r? `@ChrisDenton` try-job: aarch64-apple try-job: aarch64-msvc-1 try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Ah, debug assertions, right |
jieyouxu
force-pushed
the
fmt-write-bloat
branch
from
a51fb59 to
9059fc3
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
A few things of note since last review:
|
|
@bors try |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
added a commit
that referenced
this pull request
Nov 1, 2025
Make sure `fmt-write-bloat` doesn't vacuously pass on no symbols try-job: aarch64-apple try-job: aarch64-msvc-1 try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test for 89c50a8 failed: CI. Failed jobs:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 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.
This PR fixes the
tests/run-make/fmt-write-float/run-make test to both (1) not vacuously pass on no symbols at all, and (2) compare panics symbols under optimizations versus no optimizations.Context
Previously, the test only checks for the absence of certain panic symbols, but having no symbols was also a possible albeit vacuous way to satisfy this assertion.
Noticed in #142841 (comment).
r? @ChrisDenton
try-job: aarch64-apple
try-job: aarch64-msvc-1
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1