Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#151893 (Move the query list into a new `rustc_middle::queries` module)
- rust-lang/rust#152060 (ci: Optimize loongarch64-linux dist builders)
- rust-lang/rust#151993 (Add uv to the list of possible python runners)
- rust-lang/rust#152047 (Convert to inline diagnostics in `rustc_interface`)
- rust-lang/rust#152053 (Avoid semicolon suggestion when tail expr is error)
Failed merges:
- rust-lang/rust#152023 (Some `rustc_query_system` cleanups)
Avoid semicolon suggestion when tail expr is error
Fixesrust-lang/rust#151610
When the tail expression is Err due to recovery, HIR constructs `StmtKind::Semi(Err(..))`. The suggestion path then uses `stmt.span.with_lo(tail_expr.span.hi())` to target the semicolon, but `stmt.span == tail_expr.span` so the derived span is empty/invalid.
Move the query list into a new `rustc_middle::queries` module
This moves the query list from `rustc_middle::query` into a new `rustc_middle::queries` module. This splits up the use of the query system from the remaining implementation of it in `rustc_middle::query`, which conceptually belong to `rustc_query_system`.
The goal is to let rustc crates define queries with their own `queries` module, and this makes `rustc_middle` also fit this pattern.
The inner `queries` module used by the macros are renamed to `query_info`, so it doesn't conflict with the new outer name.
Pass on the `feedable` query modifier to macros
This passes on the `feedable` query modifier to macros so `QueryConfig.feedable` gives the correct result. Currently it's always false even for feedable queries.
Fixing this bug enables some consistency checks for feedable queries that were previously not being performed, which has a perf impact.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#148967 (const-eval: always do mem-to-mem copies if there might be padding involved)
- rust-lang/rust#152012 (Use `DEVELOPER_DIR` instead of a custom `xcode-select` script)
- rust-lang/rust#152044 (Convert to inline diagnostics in `rustc_incremental`)
- rust-lang/rust#152046 (Use glob imports for attribute parsers)
- rust-lang/rust#152054 (Distinguish error message for `#[diagnostic::on_const]` on const trait impls)
- rust-lang/rust#152059 (Fix some autodiff tests require Clto=fat)
- rust-lang/rust#152073 (Convert to inline diagnostics in `rustc_mir_dataflow`)
Distinguish error message for `#[diagnostic::on_const]` on const trait impls
context: https://github.com/rust-lang/rust/pull/149627#discussion_r2589712535
Sorry for the delay between receiving the review and submitting this patch. I'll ask the original proposer to review it.
r? estebank
const-eval: always do mem-to-mem copies if there might be padding involved
This is the final piece of the puzzle for https://github.com/rust-lang/rust/issues/148470: when copying data of a type that has padding, always do a mem-to-mem copy, so that we always preserve the source padding exactly. That prevents rustc implementation choices from leaking into user-visible behavior.
This is technically a breaking change: the example at the top of https://github.com/rust-lang/rust/issues/148470 no longer compiles with this. However, it seems very unlikely that anyone would have depended on this. My main concern is not backwards compatibility, it is performance.
Fixesrust-lang/rust#148470
---
> Actually that seems to be entirely fine, it even helps with some benchmarks! I guess the mem-to-mem codepath is actually faster than the scalar pair codepath for the copy itself. It can slow things down later since now we have to do everything bytewise, but that doesn't show up in our benchmarks and might not be very relevant after all (in particular, it only affects types with padding, so the rather common wide pointers still always use the efficient scalar representation).
>
> So that would be my proposal to for resolving this issue then: to make const-eval behavior consistent, we always copy the padding from the source to the target. IOW, potentially pre-existing provenance in the target always gets overwritten (that part is already in https://github.com/rust-lang/rust/pull/148259), and potentially existing provenance in padding in the source always gets carried over (that's https://github.com/rust-lang/rust/pull/148967). If there's provenance elsewhere in the source our existing handling is fine:
> - If it's in an integer, that's UB during const-eval so we can do whatever.
> - If it's in a pointer, the the fragments must combine back together to a pointer or else we have UB.
> - If it's in a union we just carry it over unchanged.
>
> @traviscross we should check that this special const-eval-only UB is properly reflected in the reference. Currently we have [this](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html#r-undefined.const-transmute-ptr2int) but that only talks about int2ptr, not about invalid pointer fragments at pointer type. I also wonder if this shouldn't rather be part of ["invalid values"](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html#r-undefined.validity) to make it clear that this applies recursively inside fields as well.
> EDIT: Reference PR is up at https://github.com/rust-lang/reference/pull/2091.
_Originally posted by @RalfJung in [#148470](https://github.com/rust-lang/rust/issues/148470#issuecomment-3538447283)_
> Worth noting that this does not resolve the concerns @theemathas had about `-Zextra-const-ub-checks` sometimes causing *more* code to compile. Specifically, with that flag, the behavior changes to "potentially existing provenance in padding in the source never gets carried over". However, it's a nightly-only flag (used by Miri) so while the behavior is odd, I don't think this is a problem.
_Originally posted by @RalfJung in [#148470](https://github.com/rust-lang/rust/issues/148470#issuecomment-3538450164)_
---
Related:
- https://github.com/rust-lang/rust/issues/148470
- https://github.com/rust-lang/reference/pull/2091
Convert to inline diagnostics in `rustc_attr_parsing`
Converts a crate for rust-lang/rust#151366
This PR is almost completely autogenerated by a hacky script I have locally :)
error on unsized AnonConsts
The constant evaluator does not support unsized types, however, unsized AnonConsts were never checked to be Sized, so no errors were generated on them and the constant was attempted to be constant evaluated. This caused the constant evaluator to ICE.
Add a special case for AnonConsts in rustc_hir_typeck, as suggested by @BoxyUwU in rust-lang/rust#137582. There is no checking for `#![feature(unsized_const_params)]` which should eventually revert this check when the feature becomes more implemented.
That issue is assigned to @el-ev but I started looking into this as a jumping off point / motivation to learn some compiler stuff, and I eventually got to the point of fixing it, so I'm submitting a PR anyway. So just a ping/FYI to @el-ev that I'm submitting this, sorry!
There are three relevant github issues to this ICE that I could find:
- fixesrust-lang/rust#137582
- fixesrust-lang/rust#151591
The similar issue rust-lang/rust#104685 is NOT fixed, it might be good to glance at that before verifying this particular fix, to make sure this fix is actually in the right place. (I haven't looked at it much)
r? @BoxyUwU
Check proj's parent is trait or not when checking dyn compatibility
Fixes https://github.com/rust-lang/rust/issues/151708
When checking dyn compatibility, `proj` here may point to free const whose parent is not trait. Then `TraitRef::from_assoc` will call `generics_of` on the wrong parent.
After this change, the following case without `#[type_const]` will still emit ICE same to https://github.com/rust-lang/rust/issues/149066, but different to the ICE reported in https://github.com/rust-lang/rust/issues/151708
```rust
#![feature(min_generic_const_args)]
// #[type_const]
const N: usize = 2;
trait CollectArray {
fn inner_array(&self) -> [i32; N];
}
```
r? @BoxyUwU
Forbid manual `Unpin` impls for structurally pinned types
Part of [`pin_ergonomics`](https://github.com/rust-lang/rust/issues/130494). It forbids to `impl Unpin for T` where `T` is an ADT marked with `#[pin_v2]`.
coverage: Add a test case for a previously-unknown span mismatch
- This is a revised version of https://github.com/rust-lang/rust/pull/152036.
---
In https://github.com/rust-lang/rust/pull/145643, a defensive check was added to detect spans that unexpectedly don't match the context of the function body span. There was no known way to trigger that condition, so a `debug_assert!` was added to make violations easier to notice.
A way to trigger the condition using nested macro expansions was subsequently found and reported as an ICE (in debug-assertion builds) in https://github.com/rust-lang/rust/issues/147339.
Now that we have a concrete example to investigate, we can remove the `debug_assert!` so that there is no ICE in debug-assertion builds.
- Fixes https://github.com/rust-lang/rust/issues/147339.
r? chenyukang
Use the query vtable in `query_feed` plumbing
The `query_feed` function needs to be able to do two important things with (erased) query values: hash them, and debug-print them.
Both of those are things that the query's vtable already knows how to do. So by passing in a vtable to `query_feed`, we can give it a nicer signature, avoid having to unerase values in the function itself, and clean up some caller-side code as well.
Convert to inline diagnostics in `rustc_driver_impl`
Converts a crate for rust-lang/rust#151366
This PR is almost completely autogenerated by a hacky script I have locally :)
Remove `with_no_trimmed_paths` use in query macro
We already use `with_no_trimmed_paths!` when calling query descriptors so the extra call generated by the macro is not needed.
fix: Make `--color always` always print color with `--explain`
Fixesrust-lang/rust#151643.
This changes the behaviour of `handle_explain` in `rustc_driver_impl` to always output color when the `--color always` flag is set.
r? @tgross35
Fix missing unused_variables lint when using a match guard
Within a binding pattern match guard, only real reads of a bound local impact its liveness analysis - not the fake read that is injected.
Fixesrust-lang/rust#151983
r? compiler
