Skip to content

Comments

Rollup of 8 pull requests#152982

Closed
JonathanBrouwer wants to merge 25 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-7T28A8b
Closed

Rollup of 8 pull requests#152982
JonathanBrouwer wants to merge 25 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-7T28A8b

Conversation

@JonathanBrouwer
Copy link
Contributor

Successful merges:

r? @ghost

Create a similar rollup

LaneAsade and others added 25 commits February 19, 2026 10:07
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)
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Feb 22, 2026
@rustbot rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Feb 22, 2026
@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Feb 22, 2026
@JonathanBrouwer
Copy link
Contributor Author

@bors r+ rollup=never p=5

@rust-bors
Copy link
Contributor

rust-bors bot commented Feb 22, 2026

📌 Commit 63935ec has been approved by JonathanBrouwer

It is now in the queue for this repository.

@rust-bors rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 22, 2026
@rust-bors

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…)
@rust-log-analyzer
Copy link
Collaborator

The job test-various failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
REPOSITORY                                   TAG       IMAGE ID       CREATED       SIZE
ghcr.io/dependabot/dependabot-updater-core   latest    b72a662c47e3   3 weeks ago   790MB
=> Removing docker images...
Deleted Images:
untagged: ghcr.io/dependabot/dependabot-updater-core:latest
untagged: ghcr.io/dependabot/dependabot-updater-core@sha256:57ef9cc45f72cc4258ee1baa8243bc3cd55c0a0e570b6768c37346247be35f0d
deleted: sha256:b72a662c47e31df2e7bf59368b2b83be239f02a1baa721393717711a1a719df9
deleted: sha256:3e13ccd80f19769f39008cfc6549938e1ea4905f47b028c1df2dd6085191386c
deleted: sha256:842807995a512b2c5a9b241a3aecdbe79af6b0642d96fa5460cfcf0c9d8be295
deleted: sha256:0f9074b9f46f4570eb7cb4b65fcb3c3d909f9b1d14ca66b30508117b6deda303
deleted: sha256:2ca99cb9251d19157c56b5d91c8961bb4b35196a5ca9b4ffdccbf24abbfe2a5f
---
test [ui] tests/ui/abi/arm-unadjusted-intrinsic.rs#arm ... ok
test [ui] tests/ui/abi/abi-sysv64-arg-passing.rs ... ok
test [ui] tests/ui/abi/anon-extern-mod.rs ... ok
test [ui] tests/ui/abi/bad-custom.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/abi/avr-sram.rs#disable_sram ... ok
test [ui] tests/ui/abi/avr-sram.rs#has_sram ... ok
test [ui] tests/ui/abi/avr-sram.rs#no_sram ... ok
test [ui] tests/ui/abi/c-zst.rs#aarch64-darwin ... ok
test [ui] tests/ui/abi/c-zst.rs#powerpc-linux ... ok
test [ui] tests/ui/abi/c-stack-as-value.rs ... ok
test [ui] tests/ui/abi/c-zst.rs#s390x-linux ... ok
test [ui] tests/ui/abi/c-zst.rs#sparc64-linux ... ok
---
test [ui] tests/ui/asm/aarch64/type-f16.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/asm/aarch64/arm64ec-sve.rs ... ok
test [ui] tests/ui/array-slice-vec/vector-no-ann-2.rs ... ok
test [ui] tests/ui/array-slice-vec/vector-slice-matching-8498.rs ... ok
test [ui] tests/ui/asm/aarch64v8r.rs#hf ... ok
test [ui] tests/ui/asm/asm-with-nested-closure.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/asm/aarch64v8r.rs#r82 ... ok
test [ui] tests/ui/asm/arm-low-dreg.rs ... ok
test [ui] tests/ui/asm/binary_asm_labels.rs ... ignored, only executed when the architecture is x86_64
test [ui] tests/ui/asm/binary_asm_labels_allowed.rs ... ignored, only executed when the architecture is aarch64
---
test [ui] tests/ui/asm/conditionally-sized-ptr.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/asm/const-error.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/asm/const-refs-to-static.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/asm/const-resolve-error.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/asm/aarch64v8r.rs#sf ... ok
test [ui] tests/ui/asm/empty_global_asm.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/asm/fail-const-eval-issue-121099.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/asm/generic-const.rs ... ignored, ignored on targets without inline assembly support
test [ui] tests/ui/asm/generic_const_simd_vec_len.rs ... ignored, only executed when the architecture is x86_64
test [ui] tests/ui/asm/global-asm-isnt-really-a-mir-body.rs#cfi ... ignored, ignored on targets without inline assembly support
---
test [ui] tests/ui/const-generics/occurs-check/unused-substs-3.rs ... ok
test [ui] tests/ui/const-generics/occurs-check/unused-substs-4.rs ... ok
test [ui] tests/ui/const-generics/ogca/basic.rs ... ok
test [ui] tests/ui/const-generics/occurs-check/unused-substs-5.rs ... ok
test [ui] tests/ui/const-generics/ogca/basic-fail.rs ... ok
test [ui] tests/ui/const-generics/ogca/coherence-ambiguous.rs ... ok
test [ui] tests/ui/const-generics/ogca/rhs-but-not-root.rs ... ok
test [ui] tests/ui/const-generics/opaque_types2.rs ... ok
test [ui] tests/ui/const-generics/opaque_types.rs ... ok
test [ui] tests/ui/const-generics/outer-lifetime-in-const-generic-default.rs ... ok
test [ui] tests/ui/const-generics/overlapping_impls.rs ... ok
test [ui] tests/ui/const-generics/params-in-ct-in-ty-param-lazy-norm.rs#full ... ok
---
test [ui] tests/ui/extern/issue-64655-extern-rust-must-allow-unwind.rs#thin2 ... ignored, ignored on targets without threading support
test [ui] tests/ui/extern/issue-64655-extern-rust-must-allow-unwind.rs#thin3 ... ignored, ignored on targets without threading support
test [ui] tests/ui/extern/issue-36122-accessing-externed-dst.rs ... ok
test [ui] tests/ui/extern/issue-47725.rs ... ok
test [ui] tests/ui/extern/lgamma-linkage.rs ... ignored, ignored when the architecture is wasm32 (wasi-libc does not have lgamma)
test [ui] tests/ui/extern/issue-13655.rs ... ok
test [ui] tests/ui/extern/issue-95829.rs ... ok
test [ui] tests/ui/extern/not-in-block.rs ... ok
test [ui] tests/ui/extern/unsized-extern-derefmove.rs ... ok
test [ui] tests/ui/extern/issue-80074.rs ... ok
---
test [ui] tests/ui/feature-gates/feature-gate-macro-derive.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-macro-metavar-expr-concat.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-marker_trait_attr.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-may-dangle.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-mgca-type-const-syntax.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-min-generic-const-args.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-movrs_target_feature.rs ... ignored, only executed when the architecture is x86_64
test [ui] tests/ui/feature-gates/feature-gate-more-maybe-bounds.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-min_const_fn.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-naked_functions_rustic_abi.rs ... ignored, only executed when the architecture is x86_64
---
test [ui] tests/ui/imports/ambiguous-9.rs ... ok
test [ui] tests/ui/imports/ambiguous-8.rs ... ok
test [ui] tests/ui/imports/ambiguous-glob-vs-expanded-extern.rs ... ok
test [ui] tests/ui/imports/ambiguous-import-visibility-module.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-glob-vs-multiouter.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-globvsglob.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-no-implicit-prelude.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-non-prelude-core-glob.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-non-prelude-std-glob.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-pick-core.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-pick-std.rs ... ok
---
test [ui] tests/ui/layout/post-mono-layout-cycle.rs ... ok
test [ui] tests/ui/layout/null-pointer-optimization-sizes.rs ... ok
test [ui] tests/ui/layout/randomize.rs#normal ... ok
test [ui] tests/ui/layout/reprc-power-alignment.rs ... ok
test [ui] tests/ui/layout/rigid-alias-due-to-broken-impl.rs ... ok
test [ui] tests/ui/layout/null-pointer-optimization.rs ... ok
test [ui] tests/ui/layout/randomize.rs#randomize-layout ... ok
test [ui] tests/ui/layout/struct.rs ... ok
test [ui] tests/ui/layout/rust-call-abi-not-a-tuple-ice-81974.rs ... ok
test [ui] tests/ui/layout/rigid-alias-no-params.rs ... ok
---
---- [mir-opt] tests/mir-opt/dont_reset_cast_kind_without_updating_operand.rs stdout ----
50 +         _4 = const ();
51           StorageLive(_12);
52           StorageLive(_13);
-           _13 = boxed::box_new_uninit(const <() as std::mem::SizedTypeProperties>::LAYOUT) -> [return: bb2, unwind unreachable];
+ -         _13 = boxed::box_new_uninit(const <() as std::mem::SizedTypeProperties>::LAYOUT) -> [return: bb2, unwind unreachable];
+ +         _13 = boxed::box_new_uninit(const Layout {{ size: 0_usize, align: std::ptr::Alignment {{ _inner_repr_trick: std::ptr::alignment::AlignmentEnum::_Align1Shl0 }} }}) -> [return: bb2, unwind unreachable];
54       }
55   
56       bb1: {

103 +         nop;
104           drop(_3) -> [return: bb1, unwind unreachable];
105       }
+ + }
+ + 
+ + ALLOC0 (size: 8, align: 4) {
+ +     01 00 00 00 00 00 00 00                         │ ........
106   }
107   
108 


thread '[mir-opt] tests/mir-opt/dont_reset_cast_kind_without_updating_operand.rs' panicked at src/tools/compiletest/src/runtest/mir_opt.rs:84:21:
Actual MIR output differs from expected MIR output /checkout/tests/mir-opt/dont_reset_cast_kind_without_updating_operand.test.GVN.32bit.panic-abort.diff
stack backtrace:
   5: __rustc::rust_begin_unwind
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/std/src/panicking.rs:689:5
   6: core::panicking::panic_fmt
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/core/src/panicking.rs:80:14

@rust-bors rust-bors bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 22, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Feb 22, 2026

💔 Test for 93b6a78 failed: CI. Failed job:

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 22, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Feb 22, 2026

PR #149366, which is a member of this rollup, was unapproved.
This rollup was thus also unapproved.

@rust-bors rust-bors bot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Feb 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) PG-exploit-mitigations Project group: Exploit mitigations rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants