Rollup of 5 pull requests#152967
Closed
JonathanBrouwer wants to merge 19 commits intorust-lang:mainfrom
Closed
Conversation
Otherwise, it systematically fails on: ``` error: process didn't exit successfully: `[...]/rust/build/bootstrap/debug/rustc [...]/rust/build/bootstrap/debug/rustc -vV` (exit status: 127) --- stderr [...]/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory ``` for us at least. Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
There are six small macros used in `define_callbacks` that all expand to one thing if a particular query modifier is present, and to another thing otherwise. One of these macros looks for the `arena_cache` modifier: - `query_if_arena` Two of these macros look for the `return_result_from_ensure_ok` modifier: - `query_ensure_select` - `ensure_ok_result` Three of these macros look for the `separate_provide_extern` modifier: - `local_key_if_separate_extern` - `separate_provide_extern_decl` - `separate_provide_extern_default` (There is also `query_helper_param_ty!`, but it follows a different pattern, and I will deal with it later.) The "one thing"/"another thing" is different for every macro. For most of them you can't see at the macro call site what the expansion will be; you have to look at the macro definition. This is annoying. This commit reduces the six macros into three macros: - `if_arena_cache` - `if_return_result_from_ensure_ok` - `if_separate_provide_extern` They all have the same form: they look for a modifier and then expand to one *given* thing or the other *given* thing. You can see at the call site the two possible expansions, which is much nicer. (Note: `query_if_arena` already had this form.) Ideally there would be a single macro instead of three, but I couldn't work out a way to combine them.
So that all `$( ... $name ... )*` repetitions are spread across multiple lines, even if they all fit on one line. I find this much easier to read because the `$name` repetition is the main feature of these macros.
It doesn't make much sense to put the query doc comments on these structs. (The doc comments *are* put on various query functions, where it makes more sense.)
Within `define_callbacks!`: - Use `Key<'tcx>` where possible instead of `$($K)*`. - Use `Value<'tcx>` where possible instead of `$V`. In the other `define_*!` macros: - Use `$K:ty` where possible instead of `$($K:tt)*`. - Add comments about unused `$K` and `$V` cases. - Add `()` key types to the special nodes in the `define_dep_nodes!` invocation for consistency with normal queries.
Elaborate comments. Co-authored-by: Ralf Jung <post@ralfj.de>
Due to a bug, you can currently use `key` within the `desc` block and it'll just work regardless of what actual key name you specified. A subsequent commit will fix this, so let's correct the affected queries first.
Due to a bug they aren't actually necessary! (A few queries already take advantage of this, probably unintentionally.) And the next commit will remove support for explicit `tcx` bindings in favour of implicit.
As currently written, these have big problems. - `desc` and `cache_on_disk_if` modifiers use different syntaxes to introduce `tcx`. - `desc` is mis-implemented such that the explicit binding isn't even necessary and the key name can be botched, as the previous two commits showed. (It's the `let (#tcx, #key) = (tcx, key);` line that messes things up.) It's simpler and less error-prone to simply not require explicit `tcx` bindings, and instead just make it implicitly available to these code snippets.
GVN: consider constants of primitive types as deterministic *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149366)* GVN separates MIR constants into deterministic and non-deterministic constants. Deterministic constants are defined here as: gives the exact same value each time it is evaluated. This was mainly useful because of `ConstValue::Slice` that generated an extra `AllocId` each time it appeared in the MIR. That variant has been removed. This is still useful for valtrees that hold references, which generate a fresh `AllocId` for each evaluation. This PR proposes to consider all constants of primitive type to be deterministic. If a constant of primitive type passes validation, then it does not contain provenance, so we have no risk of having a reference becoming different `AllocId`s. In particular, valtrees only are leaves. r? @ghost for perf
…ry-macros, r=Zalathar Clarify aspects of query macros Various clarity and consistency improvements to query macros. r? @Zalathar
…=oli-obk
`rustc_queries` simplifications
Queries have two ways of specifying code snippets, in `desc` and `cache_on_disk_if` blocks. An example:
```rust
query check_liveness(key: LocalDefId) -> &'tcx rustc_index::bit_set::DenseBitSet<abi::FieldIdx> {
arena_cache
desc { |tcx| "checking liveness of variables in `{}`", tcx.def_path_str(key.to_def_id()) }
cache_on_disk_if(tcx) { tcx.is_typeck_child(key.to_def_id()) }
}
```
If you need to use `tcx` in the snippet, you can use an explicit binding. But there are multiple problems with this.
- The syntax used is different in the two snippets: `|tcx|` within the block vs. `(tcx)` outside the block. (!!)
- Bug 1: In `desc` snippets you can leave out the `|tcx|` and still use `tcx`. Several existing queries do this.
- Bug 2: In `desc` snippets you can always use `key` in the snippet to refer to the key, even if that's not the identifier used in the query head.
- Finally, you can bind `tcx` and not use it, without a warning. Several existing queries do this.
I think explicit `tcx` binding is silly. Many queries need `tcx` and this macro is already super-magical, so just making `tcx` implicitly available seems fine, rather than making the query writer jump through a little syntactic hoop. This makes both the query definitions and the proc macro simpler.
r? @petrochenkov
…=JonathanBrouwer stabilize `cfg_select!` *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/149783)* tracking issue: rust-lang#115585 closes rust-lang#115585 reference PR: - rust-lang/reference#2103 # Request for Stabilization ## Summary The `cfg_select!` macro picks the expansion corresponding to the first `cfg` condition that evaluates to `true`. It simplifies complex conditional expressions. ```rust cfg_select! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } let is_unix_str = cfg_select! { unix => "unix", _ => "not unix", }; println!("{is_unix_str}"); ``` ## Semantics The expansion of a `cfg_select!` call is the right-hand side of the first `cfg` rule that evaluates to true. This can be roughly expressed using this macro: ```rust macro_rules! cfg_select { ({ $($tt:tt)* }) => {{ $crate::cfg_select! { $($tt)* } }}; (_ => { $($output:tt)* }) => { $($output)* }; ( $cfg:meta => $output:tt $($( $rest:tt )+)? ) => { #[cfg($cfg)] $crate::cfg_select! { _ => $output } $( #[cfg(not($cfg))] $crate::cfg_select! { $($rest)+ } )? } } ``` The actual implementation uses a builtin macro so that `cfg_select!` can be used both in item and expression position. ## Documentation reference PR: - rust-lang/reference#2103 ## Tests The `cfg_select!` macro is already used extensively in the rust compiler codebase. It has several dedicated tests: - [`tests/ui/check-cfg/cfg-select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/check-cfg/cfg-select.rs)tests that warnings are emitted when an unexpected `cfg` condition is used. - [`tests/ui/macros/cfg_select.rs`](https://github.com/rust-lang/rust/blob/main/tests/ui/macros/cfg_select.rs) tests that `cfg_select!` has the expected expansion, and tests that the expected syntax is accepted. ## History - rust-lang#115416 - rust-lang#117162 - rust-lang#133720 - rust-lang#135625 - rust-lang#137198 - rust-lang#138993 - rust-lang#138996 - rust-lang#143461 - rust-lang#143941 - rust-lang#145233 - rust-lang#148712 - rust-lang#149380 - rust-lang#149925 # Resolved questions # Unresolved questions The style team has decided on how to format `cfg_select!`, but this formatting has not yet been implemented. See rust-lang#144323. r? @traviscross <!-- TRIAGEBOT_START --> <!-- TRIAGEBOT_CONCERN-ISSUE_START --> > [!NOTE] > # Concerns (0 active) > > - ~~[allowing-comma-after-closing-brace](rust-lang#149783 (comment) resolved in [this comment](rust-lang#149783 (comment)) > > *Managed by `@rustbot`—see [help](https://forge.rust-lang.org/triagebot/concern.html) for details.* <!-- TRIAGEBOT_CONCERN-ISSUE_END --> <!-- TRIAGEBOT_END -->
….lib, r=clubby789 Build: Add `stdenv.cc.cc.lib` to Nix dependencies Otherwise, it systematically fails on: ``` error: process didn't exit successfully: `[...]/rust/build/bootstrap/debug/rustc [...]/rust/build/bootstrap/debug/rustc -vV` (exit status: 127) --- stderr [...]/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory ``` for us at least. Closes rust-lang#127620. @rustbot label T-bootstrap A-reproducibility
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 22, 2026
…uwer Rollup of 5 pull requests Successful merges: - #149366 (GVN: consider constants of primitive types as deterministic) - #152779 (Clarify aspects of query macros) - #152958 (`rustc_queries` simplifications) - #149783 (stabilize `cfg_select!`) - #152708 (Build: Add `stdenv.cc.cc.lib` to Nix dependencies)
Contributor
Author
|
@bors yield |
Contributor
|
Auto build cancelled. Cancelled workflows: The next pull request likely to be tested is #152965. |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Feb 22, 2026
…uwer Rollup of 5 pull requests Successful merges: - #149366 (GVN: consider constants of primitive types as deterministic) - #152779 (Clarify aspects of query macros) - #152958 (`rustc_queries` simplifications) - #149783 (stabilize `cfg_select!`) - #152708 (Build: Add `stdenv.cc.cc.lib` to Nix dependencies)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
💔 Test for 51f1671 failed: CI. Failed job:
|
Contributor
|
PR #149783, which is a member of this rollup, was unapproved. |
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.
Successful merges:
rustc_queriessimplifications #152958 (rustc_queriessimplifications)cfg_select!#149783 (stabilizecfg_select!)stdenv.cc.cc.libto Nix dependencies #152708 (Build: Addstdenv.cc.cc.libto Nix dependencies)r? @ghost
Create a similar rollup