Make Enzyme has dependent on LLVM hash
This issue was encountered a few times by autodiff contributors.
Closes https://github.com/rust-lang/rust/issues/152969
Just adding the llvm hash here triggered a rebuild of Enzyme locally, but I'll admit I didn't try it with a real llvm submodule update.
r? @Kobzol
miri-test-libstd: use --tests and update some comments
rust-lang/rust#153143 added `./x test --tests` matching `cargo --tests`, which is exactly what Miri wants when testing the standard library. So let's use it for that. We can then also remove a hack in `library/alloctests/benches/vec_deque_append.rs`.
Also update the comment for why the other benchmarks still need to be disabled in Miri, and remove some `cfg_attr` that seem unnecessary since the entire crate that contains them is already disabled in Miri. Those were copied over in https://github.com/rust-lang/rust/commit/b8fa843a1a60146b93ca5b1d11bbe23c1b1076f3 -- they used to be needed since benches and tests were in the same crate, but they aren't any more.
Introduce `for_each_query_vtable!` to move more code out of query macros
After https://github.com/rust-lang/rust/pull/153114 moved a few for-each-query functions into the big `rustc_query_impl::plumbing` macro, I have found that those functions became much harder to navigate and modify, because they no longer have access to ordinary IDE features in rust-analyzer. Even *finding* the functions is considerably harder, because a plain go-to-definition no longer works smoothly.
This PR therefore tries to move as much of that code back out of the macro as possible, with the aid of a smaller `for_each_query_vtable!` helper macro. A typical use of that macro looks like this:
```rust
for_each_query_vtable!(ALL, tcx, |query| {
query_key_hash_verify(query, tcx);
});
```
The result is an outer function consisting almost entirely of plain Rust code, with all of the usual IDE affordances expected of normal Rust code. Because it uses plain Rust syntax, it can also be formatted automatically by rustfmt.
Adding another layer of macro-defined macros is not something I propose lightly, but in this case I think the improvement is well worth it:
- The outer functions can once again be defined as “normal” Rust functions, right next to their corresponding inner functions, making navigation and modification much easier.
- The closure expression is ordinary Rust code that simply gets repeated ~300 times in the expansion, once for each query, in order to account for the variety of key/value/cache types used by different queries. Even within the closure expression, IDE features still *mostly* work, which is an improvement over the status quo.
- For future maintainers looking at the call site, the macro's effect should hopefully be pretty obvious and intuitive, reducing the need to even look at the helper macro. And the helper macro itself is largely straightforward, with its biggest complication being that it necessarily uses the `$name` metavar from the outer macro.
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
Unify same-span labels in move error diagnostics
Fixesrust-lang/rust#153506.
When there's a single binding in a move error, we emit "data moved here" and "move occurs because ... does not implement the Copy trait" as two separate labels on the same span. This combines them into one label via a new `TypeNoCopy::LabelMovedHere` variant.
The multi-binding case still uses separate labels + a note since they point at different spans.
cc @estebank
interpret: go back to regular string interpolation for error messages
Using the translatable diagnostic infrastructure adds a whole lot of boilerplate which isn't actually useful for const-eval errors, so let's get rid of it. This effectively reverts https://github.com/rust-lang/rust/pull/111677. That PR effectively added 1000 lines and this PR only removes around 600 -- the difference is caused by (a) keeping some of the types around for validation, where we can use them to share error strings and to trigger the extra help for pointer byte shenanigans during CTFE, and (b) this not being a full revert of rust-lang/rust#111677; I am not touching diagnostics outside the interpreter such as all the const-checking code which also got converted to fluent in the same PR.
The last commit does something similar for `LayoutError`, which also helps deduplicate a bunch of error strings. I can make that into a separate PR if you prefer.
r? @oli-obk
Fixes https://github.com/rust-lang/rust/issues/113117
Fixes https://github.com/rust-lang/rust/issues/116764
Fixes https://github.com/rust-lang/rust/issues/112618
Simplify `type_of_opaque`.
There is a bunch of complexity supporting the "cannot check whether the hidden type of opaque type satisfies auto traits" error that shows up in `tests/ui/impl-trait/auto-trait-leak.rs`. This is an obscure error that shows up in a single test. If we are willing to downgrade that error message to a cycle error, we can do the following.
- Simplify the `type_of_opaque` return value.
- Remove the `cycle_stash` query modifier.
- Remove the `CyclePlaceholder` type.
- Remove the `SelectionError::OpaqueTypeAutoTraitLeakageUnknown` variant.
- Remove a `FromCycleError` impl.
- Remove `report_opaque_type_auto_trait_leakage`.
- Remove the `StashKey::Cycle` variant.
- Remove the `CycleErrorHandling::Stash` variant.
That's a lot! I think this is a worthwhile trade-off.
r? @oli-obk
Avoid ICE when an EII declaration conflicts with a constructor
Fixesrust-lang/rust#153502
When an `#[eii]` declaration conflicts with a tuple-struct constructor of the same name, error recovery can resolve
the EII target to the constructor instead of the generated foreign item. `compare_eii_function_types` then assumes
that target is a foreign function and later ICEs while building diagnostics.
This pull request adds an early guard in `compare_eii_function_types` to skip EII signature comparison unless the resolved target is actually a foreign function.
Fix ICE in fn_delegation when child segment resolves to a trait
Fixesrust-lang/rust#153420
When a delegation path like `reuse Trait::<> as bar4` has only one segment resolving to a trait (not a function), the child args processing in `get_delegation_user_specified_args` called `lower_generic_args_of_path` with `self_ty = None`. Since the trait's generics have `has_self = true`, this triggered
`assert!(self_ty.is_some())`.
Fix by computing and providing `self_ty` when the child segment's `def_id` has `has_self`. In valid delegation code the child segment always resolves to a function, so this only affects error recovery.
When a delegation path like `reuse Trait::<> as bar4` has a child segment
that resolves to a trait instead of a function, the compiler would ICE
because `lower_generic_args_of_path` asserts that `self_ty` is `Some`
when `has_self` is true and `parent` is `None`.
Fix this by filtering out non-function child segments early using
`.filter()` in the method chain, so that when the child segment resolves
to a trait (error recovery for E0423), we skip generic args computation
entirely and return an empty list via `unwrap_or_default()`.
Also make `get_segment` return `Option` by using `opt_def_id()` instead
of `def_id()` to gracefully handle unresolved segments.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#153072 (Allow merging all libcore/alloc doctests into a single binary)
- rust-lang/rust#153408 (miri: make read_discriminant UB when the tag is not in the validity range of the tag field)
- rust-lang/rust#153674 (Detect inherent method behind deref being shadowed by trait method)
- rust-lang/rust#153689 (Eliminate `QueryLatchInfo`.)
There is a bunch of complexity supporting the "cannot check whether the
hidden type of opaque type satisfies auto traits" error that shows up in
`tests/ui/impl-trait/auto-trait-leak.rs`. This is an obscure error that
shows up in a single test. If we are willing to downgrade that error
message to a cycle error, we can do the following.
- Simplify the `type_of_opaque` return value.
- Remove the `cycle_stash` query modifier.
- Remove the `CyclePlaceholder` type.
- Remove the `SelectionError::OpaqueTypeAutoTraitLeakageUnknown`
variant.
- Remove a `FromCycleError` impl.
- Remove `report_opaque_type_auto_trait_leakage`.
- Remove the `StashKey::Cycle` variant.
- Remove the `CycleErrorHandling::Stash` variant.
That's a lot! I think this is a worthwhile trade-off.
Eliminate `QueryLatchInfo`.
The boolean `complete` flag indicates whether the `waiters` vec is still in use, which means the `waiters` vec must be empty when `complete` is true. This is achieved by using `drain` on the waiters just after `complete` is set.
We can do better by using the type system to make invalid combinations impossible. This commit removes `complete` and puts the waiters inside an `Option`. `Some` means the query job is still active, and `None` once it is complete. And `QueryLatchInfo` is eliminated.
(The `Arc<Mutex<Option<Vec<Arc<QueryWaiter<'tcx>>>>>>` type is a mouthful, but when it's all in one place I find it easier to understand than when it's split across two types. And we can use `Option` methods like `as_ref`, `as_mut`, and `take`, which is nice.)
r? @petrochenkov
Detect inherent method behind deref being shadowed by trait method
```
error[E0277]: the trait bound `Rc<RefCell<S>>: Borrow<S>` is not satisfied
--> $DIR/shadowed-intrinsic-method-deref.rs:16:22
|
LL | let sb : &S = &s.borrow();
| ^^^^^^ the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
|
help: the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
but trait `Borrow<RefCell<S>>` is implemented for it
--> $SRC_DIR/alloc/src/rc.rs:LL:COL
= help: for that trait implementation, expected `RefCell<S>`, found `S`
= note: there's an inherent method on `RefCell<S>` of the same name, which can be auto-dereferenced from `&RefCell<T>`
help: to access the inherent method on `RefCell<S>`, use the fully-qualified path
|
LL - let sb : &S = &s.borrow();
LL + let sb : &S = &RefCell::borrow(&s);
|
```
In the example above, method `borrow` is available both on `<RefCell<S> as Borrow<S>>` *and* on `RefCell<S>`. Adding the import `use std::borrow::Borrow;` causes `s.borrow()` to find the former instead of the latter. We now point out that the other exists, and provide a suggestion on how to call it.
Fixrust-lang/rust#41906. CC rust-lang/rust#153662.
miri: make read_discriminant UB when the tag is not in the validity range of the tag field
Arguably, reading an enum discriminant is an operation that uses the "type" of the discriminant field -- and therefore it should fail when the value in that field isn't valid at that type. Therefore, code like this should be UB:
```rust
fn main() {
unsafe {
let x = 12u8;
let x_ptr: *const u8 = &x;
let cast_ptr = x_ptr as *const Option<bool>;
// Reading the discriminant should fail since the tag value is not in the valid
// range for the tag field.
let _val = matches!(*cast_ptr, None);
//~^ ERROR: invalid tag
}
}
```
However, Miri currently sees no UB here. (MiniRust does see UB.) This is because we never actually check whether the tag we read is in the validity range for its field. So let's add such a check, and a corresponding test.
In fact, we have to do this check, since the codegen backend adds range metadata on the discriminant load, as can be seen in [this example](https://play.rust-lang.org/?version=stable&mode=release&edition=2024&gist=02ef5e80fdfe61540e44198dd827b630). In other words, the above code has UB in LLVM IR but not in Miri, which is a critical Miri bug.
Allow merging all libcore/alloc doctests into a single binary
This is only the changes needed to *allow* merging the tests. This doesn't actually turn doctest merging on in bootstrap. I think that might be a useful follow-up, since it makes them much faster to run, but it's not without downsides because it means we'll no longer be testing that doctests have all necessary `feature()` attributes.
The motivation for this change is to run the tests with `-C instrument-coverage` and then generate a coverage report from the output. Currently, this is very expensive because it requires parsing DWARF for each doctest binary. Merging the binaries decreases the time taken from several hours to ~30 seconds.
---
There are several parts to this change, most of which are independent and I'm happy to split out into other PRs.
- Upgrade process spawning logging from debug->info so it's easier to see, including in a rustdoc built without debug symbols.
- Core doctests now support being run with `-C panic=abort`. Ferrocene needs this downstream for complicated reasons; it's a one-line change so I figured it's not a big deal.
- Downgrade errors about duplicate features from a hard error to a warning. The meaning is clear here, and doctest merging often creates duplicate features since it lifts them all to the crate root. This involves changes to the compiler but generally I expect this to be low-impact.
- Enable this new warning, as well as several related feature lints, in rustdoc. By default rustdoc doesn't lint on anything except the lints it manually adds.
- Rustdoc now treats `allow(incomplete_features)` as a crate-level attribute, just like `internal_features`. Without this, it's possible to get hard errors if rustdoc lifts features to the crate level but not `allow`s.
- Core doctests now support being built with `--merge-doctests=yes`. In particular, I removed a few `$crate` usages and explicitly marked a few doctests as `standalone_crate`.
improve target feature diagnostic
And convert the test to use `minicore` so that it runs regardless of the target. This is the only test for many of these target feature diagnostics, so it's nice that it runs anywhere.
r? JonathanBrouwer
The test here is mostly for legal places for the attribute, is that still how that should be tested?
rustdoc: rename `--emit` names
These new names are pithier and match up with the rest of our terminology:
- `--emit=html-static-files` matches the default name of the directory that it actually emits, which is `static.files` (the hyphen is used for emit because every other emit option uses hyphens, but the directory uses a dot because we don't want its name to conflict with a crate).
- `--emit=html-non-static-files` matches the convention that emit is a noun, not an adjective, and it logically groups with other data formats.
This commit changes the docs, but leaves in support for the old names, to break the cycle with cargo and docs.rs. This commit needs merged, then cargo and docs.rs will be updated to use the new names, then, finally, the old names will be removed.
CC https://github.com/rust-lang/rust/pull/146220#issuecomment-3976454076
The boolean `complete` flag indicates whether the `waiters` vec is still
in use, which means the `waiters` vec must be empty when `complete` is
true. This is achieved by using `drain` on the waiters just after
`complete` is set.
We can do better by using the type system to make invalid combinations
impossible. This commit removes `complete` and puts the waiters inside
an `Option`. `Some` means the query job is still active, and `None` once
it is complete. And `QueryLatchInfo` is eliminated.
(The `Arc<Mutex<Option<Vec<Arc<QueryWaiter<'tcx>>>>>>` type is a
mouthful, but when it's all in one place I find it easier to understand
than when it's split across two types. And we can use `Option` methods
like `as_ref`, `as_mut`, and `take`, which is nice.)
These new names are pithier and match up with the rest of our
terminology:
- `--emit=html-static-files` matches the default name of the directory that
it actually emits, which is `static.files` (the hyphen is used for
emit because every other emit option uses hyphens, but the directory
uses a dot because we don't want its name to conflict with a crate).
- `--emit=html-non-static-files` matches the convention that emit is a noun,
not an adjective. It also matches up with static-files, and it
logically groups with other data formats.
This commit changes the docs, but leaves in support for the old names,
to break the cycle with cargo and docs.rs. This commit needs merged,
then cargo and docs.rs will be updated to use the new names, then,
finally, the old names will be removed.
```
error[E0277]: the trait bound `Rc<RefCell<S>>: Borrow<S>` is not satisfied
--> $DIR/shadowed-intrinsic-method-deref.rs:16:22
|
LL | let sb : &S = &s.borrow();
| ^^^^^^ the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
|
help: the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
but trait `Borrow<RefCell<S>>` is implemented for it
--> $SRC_DIR/alloc/src/rc.rs:LL:COL
= help: for that trait implementation, expected `RefCell<S>`, found `S`
= note: there's an inherent method on `RefCell<S>` of the same name, which can be auto-dereferenced from `&RefCell<T>`
help: to access the inherent method on `RefCell<S>`, use the fully-qualified path
|
LL - let sb : &S = &s.borrow();
LL + let sb : &S = &RefCell::borrow(&s);
|
```
In the example above, method `borrow` is available both on `<RefCell<S> as Borrow<S>>` *and* on `RefCell<S>`. Adding the import `use std::borrow::Borrow;` causes `s.borrow()` to find the former instead of the latter. We now point out that the other exists, and provide a suggestion on how to call it.
Rollup of 13 pull requests
Successful merges:
- rust-lang/rust#149130 (Implement coercions between `&pin (mut|const) T` and `&(mut) T` when `T: Unpin`)
- rust-lang/rust#153143 (Allow `./x test` to run tests without doc tests and without benchmarks)
- rust-lang/rust#153471 (Refactor `ActiveJobGuard`)
- rust-lang/rust#153595 (`QueryLatch` cleanups)
- rust-lang/rust#153653 (scalable vector: type renames and simple checks)
- rust-lang/rust#152302 (fix: don't suggest replacing `env!("CARGO_BIN_NAME")` with itself)
- rust-lang/rust#153283 (feat(rustdoc-json): Add optional support for rkyv (de)serialization)
- rust-lang/rust#153479 (Add rationale for intentional potential_query_instability allows)
- rust-lang/rust#153533 (Fix LegacyKeyValueFormat report from docker build: miscellaneous)
- rust-lang/rust#153600 (add test for proc-macros with custom panic payloads)
- rust-lang/rust#153643 (Avoid projection-only suggestions for inherent assoc types)
- rust-lang/rust#153657 (triagebot: remove myself from some mention groups)
- rust-lang/rust#153659 (Mark an unreachable match arm as such)
Remove `TyCtxt::node_lint` method and `rustc_middle::lint_level` function
Part of https://github.com/rust-lang/rust/issues/153099.
With this PR, we can finally get rid of `lint_level`. \o/
r? @JonathanBrouwer
Move `Spanned`.
It's defined in `rustc_span::source_map` which doesn't make any sense because it has nothing to do with source maps. This commit moves it to the crate root, a more sensible spot for something this basic.
r? @JonathanBrouwer
Remove `FromCycleError` trait
Currently `QueryVTable`'s `value_from_cycle_error` function pointer uses the `FromCycleError` trait to call query cycle handling code and to construct an erroneous query output value. This trick however relies too heavily on trait impl specialization and makes those impls inconsistent (which is bad AFAIK). Instead this PR directly modifies `value_from_cycle_error` function pointer upon vtable initialization and gets rid of `FromCycleError`.
Removal of `FromCycleError` might also be a desired change for some developers involved in the query system development due to some other reasons.
This PR is split up into two commits. **Code formatting changes are isolated into the second commit for better git diffs in the first one.** Nice and simple refactor PR.
I got this idea from https://github.com/rust-lang/rust/pull/153470#issuecomment-4011101113 discussion and thought it would be a pretty quick change to implement.
r? @nnethercote
I think this PR would benefit from your reviewer polish.
Introduce granular tidy_ctx's check in extra_checks
## Changes
This PR does:
- Extract sub checks in extra_checks to each function which takes a reference of TidyCtx
- Also extract python/npm dependency install steps to functions. They also calls tidy_ctx.start_check()
The changes introduce some benefits:
- A failure on one sub-check doesn't stop other sub-check (except py/npm install functions. Because some sub-checks rely on them)
- A failure on a sub-check is tracked on TidyCtx's error check
Verbose output (shortened):
<img width="904" height="1251" alt="image" src="https://github.com/user-attachments/assets/53df4029-a820-467e-b849-ac05c02b396e" />
## Question
I considered that I would decompose each sub-check more so that main.rs calls sub-checks directly and those sub-checks are executed concurrently. But to do so, I think
1. main.rs has to know some implementation details of extra_checks (for example, it might need to know ExtraCheckArg to decide which sub-checks should be called or not), and/or
2. we should decompose extra_checks/ dir to utilize check! macro for sub-checks.
I'd like to know your opinion/suggestion.
Mark an unreachable match arm as such
Synchronize which elements have code paths and which are unreachable betwen def collector and build reduced graph.
Found while analyzing on how to best merge these two visitors in a reviewable way
r? @petrochenkov
Avoid projection-only suggestions for inherent assoc types
Fixesrust-lang/rust#153539.
Type mismatch diagnostics in `note_and_explain_type_err` currently route both `ty::Projectio`n and `ty::Inherent`
through the same associated-type suggestion path. For inherent associated types, that path can reach helpers that
are only valid for trait projections.
Urhengulas