Exhaustively specify names and stability of --print values#148990
Merged
bors merged 2 commits intorust-lang:mainfrom Nov 21, 2025
Merged
Exhaustively specify names and stability of --print values#148990bors merged 2 commits intorust-lang:mainfrom
--print values#148990bors merged 2 commits intorust-lang:mainfrom
Conversation
rustbot
added
S-waiting-on-review
Collaborator
|
rustbot has assigned @WaffleLapkin. Use |
Member
Author
|
Because r-a doesn't support macro-rules derives yet (rust-lang/rust-analyzer#21043), autocomplete fails for any items introduced by the derive. So I've been reluctant to macro-rules derives more widely within the compiler. But in this case there's a relatively simple workaround, which is to alias the trait associated constant to a regular associated constant. |
WaffleLapkin
approved these changes
Nov 20, 2025
Collaborator
|
This PR was rebased onto a different main 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. |
Member
Author
|
Rebased and addressed the nit; waiting on PR CI. |
Member
Author
|
@bors r=WaffleLapkin |
Collaborator
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Nov 21, 2025
Exhaustively specify names and stability of `--print` values While trying to add a new unstable `--print` kind for use by compiletest, I found that the relevant code is quite awkward to work with, for a few reasons: - It's spread across various parts of a multi-thousand-line source file. - All newly-added `PrintKind` values are automatically treated as *stable*, unless they are explicitly marked as unstable in a helper function far away. - Parsing `--print` values relies on a separate table of name/value mappings, but there's no exhaustiveness check for that table. This PR therefore: - Extracts the relevant code into its own `print_request` submodule. - Uses a macro-rules derive to obtain an exhaustive list of values. - Uses exhaustive matches to associate a name and stability status with each `PrintKind` value. --- The first commit moves code to a separate module; the second commit contains actual changes. There should be no change to compiler output.
Collaborator
Member
Author
|
Yielding to enclosing rollup. @bors retry |
bors
added a commit
that referenced
this pull request
Nov 21, 2025
Rollup of 5 pull requests Successful merges: - #148990 (Exhaustively specify names and stability of `--print` values) - #149127 (unwrap ret ty of `iter::ArrayChunks::into_remainder` ) - #149134 (std: sys: net: uefi: Implement read_vectored) - #149135 (Constify `residual_into_try_type`) - #149160 (Check for intrinsic to fn ptr casts in unified coercions) r? `@ghost` `@rustbot` modify labels: rollup
Collaborator
rust-timer
added a commit
that referenced
this pull request
Nov 21, 2025
Rollup merge of #148990 - Zalathar:print-kind, r=WaffleLapkin Exhaustively specify names and stability of `--print` values While trying to add a new unstable `--print` kind for use by compiletest, I found that the relevant code is quite awkward to work with, for a few reasons: - It's spread across various parts of a multi-thousand-line source file. - All newly-added `PrintKind` values are automatically treated as *stable*, unless they are explicitly marked as unstable in a helper function far away. - Parsing `--print` values relies on a separate table of name/value mappings, but there's no exhaustiveness check for that table. This PR therefore: - Extracts the relevant code into its own `print_request` submodule. - Uses a macro-rules derive to obtain an exhaustive list of values. - Uses exhaustive matches to associate a name and stability status with each `PrintKind` value. --- The first commit moves code to a separate module; the second commit contains actual changes. There should be no change to compiler output.
Member
Author
|
Bors no, this has already merged. @bors r- |
bors
added
S-waiting-on-author
Member
|
@bors r- retry |
bors
added
S-waiting-on-bors
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
5 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.
While trying to add a new unstable
--printkind for use by compiletest, I found that the relevant code is quite awkward to work with, for a few reasons:PrintKindvalues are automatically treated as stable, unless they are explicitly marked as unstable in a helper function far away.--printvalues relies on a separate table of name/value mappings, but there's no exhaustiveness check for that table.This PR therefore:
print_requestsubmodule.PrintKindvalue.The first commit moves code to a separate module; the second commit contains actual changes.
There should be no change to compiler output.