Rollup of 8 pull requests#152982
Closed
JonathanBrouwer wants to merge 25 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.
…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)
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.
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
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
…, 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)
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 8 pull requests Successful merges: - #149366 (GVN: consider constants of primitive types as deterministic) - #152779 (Clarify aspects of query macros) - #152958 (`rustc_queries` simplifications) - #152385 (Feature gate for defaulted associated type_consts with associated_type_defaults ) - #152708 (Build: Add `stdenv.cc.cc.lib` to Nix dependencies) - #152921 (Add build.rustdoc option to bootstrap config) - #152926 (Fix ICE when an associated type is wrongly marked as `final`) - #152927 (Index expressions rendered the index: subexpression as the id, instea…)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
💔 Test for 93b6a78 failed: CI. Failed job:
|
Contributor
|
PR #149366, 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)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