editorconfig: css uses tabs
Tidy enforces the fact that css files use tabs, but currently `.editorconfig` says everything that isn't llvm or a Makefile should always use spaces. This PR makes it so all editors that honor `.editorconfig` will use the correct indentation for css files.
unused_macro_rules switched used and unused comments
Incorrect swapping of "used" and "unused".
The lint example:
```rust
#[warn(unused_macro_rules)]
macro_rules! unused_empty {
(hello) => { println!("Hello, world!") }; // This rule is unused
() => { println!("empty") }; // This rule is used
}
fn main() {
unused_empty!(hello);
}
```
It is clearly using the `(hello)` case. Yet it is labeled as "unused".
This PR fixed that small issue and corrects the mistake.
fix(query): Pass Query Key to `value_from_cycle_error`
### Summary:
Pass the query key directly to `value_from_cycle_error` so that `FromCycleError` impls (notably `FnSig`) can use the recovered query's `DefId` instead of relying on `cycle[0]`, which is arbitrarily rotated by the parallel deadlock handler.
As suggested in [#153644 (comment)](https://github.com/rust-lang/rust/pull/153644#issuecomment-4030645331).
Closesrust-lang/rust#153391
r? @nnethercote
cc @zetanumbers
Fix some comments about dataflow analysis.
Mostly in the examples in `initialized.rs`. In particular, the `EverInitializedPlaces` example currently doesn't cover how it's initialization sites that are tracked, rather than local variables (that's the `b_0`/`b_1` distinction in the example.)
r? @cjgillot
Don't add empty target features for target-cpu=native on macOS
LLVM does not support host feature detection (only host cpu detection) on apple platforms. As such, the returned feature string will be empty. Adding this empty string to the target-features attribute results in a verifier error on LLVM 22.
Fix this by not adding the empty string to the target features. The reason why this was not caught by the target-cpu-native test is that it requires a function that adds *some* target features, otherwise the attribute is omitted entirely. We achieve this with a somewhat peculiar construction that enables `neon` if it's already enabled. (This is to avoid enabling it on softfloat targets.)
Fixes https://github.com/rust-lang/rust/issues/153397.
LLVM does not support host feature detection (only host cpu
detection) on apple platforms. As such, the returned feature
string will be empty. Adding this empty string to the target-features
attribute results in a verifier error on LLVM 22.
Fix this by not adding the empty string to the target features.
The reason why this was not caught by the target-cpu-native test
is that it requires a function that adds *some* target features,
otherwise the attribute is omitted entirely. We achieve this with
a somewhat peculiar construction that enables `neon` if it's
already enabled. (This is to avoid enabling it on softfloat targets.)
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.
Jonathan Brouwer