Rollup of 7 pull requests#152986
Merged
rust-bors[bot] merged 19 commits intorust-lang:mainfrom Feb 22, 2026
Merged
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.
…d of actually showing the content of the subexpression This meant the content of the subexpression was completely missing from tree view (as the id did not reference anything)
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.
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
…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
…, r=BoxyUwU Feature gate for defaulted associated type_consts with associated_type_defaults *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152385)* This PR for issue rust-lang#130288 extends a feature gate that was already present for defaulted associated types to defaulted type consts under associated_type_defaults. Code added: ``` if ctxt == AssocCtxt::Trait && rhs.is_some() { gate!( &self, associated_type_defaults, i.span, "associated type defaults are unstable" ); } ``` Error produced: ``` error[E0658]: associated type defaults are unstable --> $DIR/type-const-associated-default.rs:4:5 | LL | type const N: usize = 10; | ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue rust-lang#29661 <rust-lang#29661> for more information = help: add `#![feature(associated_type_defaults)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date warning: the feature `min_generic_const_args` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/type-const-associated-default.rs:1:12 | LL | #![feature(min_generic_const_args)] | ^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue rust-lang#132980 <rust-lang#132980> for more information = note: `#[warn(incomplete_features)]` on by default error: aborting due to 1 previous error; 1 warning emitted For more information about this error, try `rustc --explain E0658`. ``` Thanks to @BoxyUwU for the guidance on this issue.
….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
…r=Kobzol Add build.rustdoc option to bootstrap config This adds a bootstrap config option `build.rustdoc` to be able to override the stage0 `rustdoc` binary. When unspecified, this defaults to the existing behavior of using the `rustdoc` binary in the same directory as `rustc`, making this a backward-compatible change. ### Motivation The existing behavior does not seem to be documented and can be surprising. By adding the new option, the behavior gets documented in `bootstrap.example.toml`. I ran into this because I was experimenting with a build with a configuration like this: ``` build.rustc = "/usr/bin/rustc-1.92" build.cargo = "/usr/bin/cargo-1.92" ``` This was on Ubuntu where the packages `rustc-1.92` and `cargo-1.92` place symlinks at these locations. This resulted in failure as the bootstrap process tried to run doc tests on `tidy` using a binary `/usr/bin/rustdoc` which did not exist. It took some digging to understand where that path `/usr/bin/rustdoc` was coming from. @rustbot label +A-bootstrap-config
…ease Fix ICE when an associated type is wrongly marked as `final` Fixes: rust-lang#152797. cc @mu001999 .
…expressions, r=TaKO8Ki Index expressions rendered the index: subexpression as the id, instea… …d of actually showing the content of the subexpression This meant the content of the subexpression was completely missing from tree view (as the id did not reference anything)
rustbot
added
A-query-system
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors
bot
added
merged-by-bors
Contributor
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 1500f0f47f In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 1500f0f (parent) -> c78a294 (this PR) Test differencesShow 200 test diffsStage 1
Stage 2
Additionally, 194 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard c78a29473a68f07012904af11c92ecffa68fcc75 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
This was referenced Feb 22, 2026
Collaborator
|
Finished benchmarking commit (c78a294): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -1.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 483.037s -> 479.878s (-0.65%) |
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
9 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.
Successful merges:
rustc_queriessimplifications #152958 (rustc_queriessimplifications)stdenv.cc.cc.libto Nix dependencies #152708 (Build: Addstdenv.cc.cc.libto Nix dependencies)final#152926 (Fix ICE when an associated type is wrongly marked asfinal)r? @ghost
Create a similar rollup