Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#134536 (Lint on fn pointers comparisons in external macros)
- rust-lang/rust#141069 (Suggest mut when possbile for temporary value dropped while borrowed)
- rust-lang/rust#141934 (resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes)
- rust-lang/rust#142034 (Detect method not being present that is present in other tuple types)
- rust-lang/rust#142402 (chore(doctest): Remove redundant blank lines)
- rust-lang/rust#142406 (Note when enum variants shadow an associated function)
- rust-lang/rust#142407 (Remove bootstrap adhoc group)
- rust-lang/rust#142408 (Add myself (WaffleLapkin) to review rotation)
- rust-lang/rust#142418 (Remove lower_arg_ty as all callers were passing `None`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions
This adds back the `unsupported_calling_conventions` lint that was removed in https://github.com/rust-lang/rust/pull/129935, in order to start the process of dealing with https://github.com/rust-lang/rust/issues/137018. Specifically, we are going for the plan laid out [here](https://github.com/rust-lang/rust/issues/137018#issuecomment-2672118326):
- thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
- vectorcall should only be accepted on x86-32 and x86-64
The difference to the status quo is that:
- We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
- We stop accepting cdecl on targets that are non-x86-32
- (There is no difference for thiscall, this was already a hard error on non-x86-32)
- We stop accepting vectorcall on targets that are windows && non-x86-*
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.
try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixesrust-lang/rust#121429
Move coroutine_by_move_body_def_id into the big check_crate body owner loop
This avoids starting a parallel loop in sequence and instead runs all the queries for a specific DefId together.
Verbose suggestion to make param `const`
```
error[E0747]: type provided when a constant was expected
--> $DIR/invalid-const-arguments.rs:10:19
|
LL | impl<N> Foo for B<N> {}
| ^
|
help: consider changing this type parameter to a const parameter
|
LL - impl<N> Foo for B<N> {}
LL + impl<const N: u8> Foo for B<N> {}
|
```
Part of rust-lang/rust#141973.
```
error[E0747]: type provided when a constant was expected
--> $DIR/invalid-const-arguments.rs:10:19
|
LL | impl<N> Foo for B<N> {}
| ^
|
help: consider changing this type parameter to a const parameter
|
LL - impl<N> Foo for B<N> {}
LL + impl<const N: u8> Foo for B<N> {}
|
```
`slice.get(i)` should use a slice projection in MIR, like `slice[i]` does
`slice[i]` is built-in magic, so ends up being quite different from `slice.get(i)` in MIR, even though they're both doing nearly identical operations -- checking the length of the slice then getting a ref/ptr to the element if it's in-bounds.
This PR adds a `slice_get_unchecked` intrinsic for `impl SliceIndex for usize` to use to fix that, so it no longer needs to do a bunch of lines of pointer math and instead just gets the obvious single statement. (This is *not* used for the range versions, since `slice[i..]` and `slice[..k]` can't use the mir Slice projection as they're using fenceposts, not indices.)
I originally tried to do this with some kind of GVN pattern, but realized that I'm pretty sure it's not legal to optimize `BinOp::Offset` to `PlaceElem::Index` without an extremely complicated condition. Basically, the problem is that the `Index` projection on a dereferenced slice pointer *cares about the metadata*, since it's UB to `PlaceElem::Index` outside the range described by the metadata. But then you cast the fat pointer to a thin pointer then offset it, that *ignores* the slice length metadata, so it's possible to write things that are legal with `Offset` but would be UB if translated in the obvious way to `Index`. Checking (or even determining) the necessary conditions for that would be complicated and error-prone, whereas this intrinsic-based approach is quite straight-forward.
Zero backend changes, because it just lowers to MIR, so it's already supported naturally by CTFE/Miri/cg_llvm/cg_clif.
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
Specifically `TyAlias`, `Enum`, `Struct`, `Union`. So the fields match
the textual order in the source code.
The interesting part of the change is in
`compiler/rustc_hir/src/hir.rs`. The rest is extremely mechanical
refactoring.
GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants
* 1st commit: Partially addresses [#136204](https://github.com/rust-lang/rust/issues/136204) by turning const eval errors from post to pre-mono for free lifetime-generic constants.
* As the linked issue/comment states, on master there's a difference between `const _: () = panic!();` (pre-mono error) and `const _<'a>: () = panic!();` (post-mono error) which feels wrong.
* With this PR, both become pre-mono ones!
* 2nd commit: Oof, yeah, I missed that in the initial impl!
This doesn't fully address #136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `const _UNUSED: () = () where for<'_delay> String: Copy;` which can also be found over at the tracking issue #113521.
r? compiler-errors or reassign
Rename `{GenericArg,Term}::unpack()` to `kind()`
A well-deserved rename IMO.
r? `@oli-obk` or `@lcnr` (or anyone)
cc `@rust-lang/types,` but I'd be surprised if this is controversial.
Defer evaluating type system constants when they use infers or params
Split out of #137972, the parts necessary for associated const equality and min generic const args to make progress and have correct semantics around when CTFE is invoked. According to a [previous perf run](https://perf.rust-lang.org/compare.html?start=93257e2d20809d82d1bc0fcc1942480d1a66d7cd&end=01b4cbf0f47c3f782330db88fa5ba199bba1f8a2&stat=instructions:u) of adding the new `const_arg_kind` query we should expect minor regressions here.
I think this is acceptable as we should be able to remove this query relatively soon once mgca is more complete as we'll then be able to implement GCE in terms of mgca and rip out `GCEConst` at which point it's trivial to determine what kind of anon const we're dealing with (either it has generics and is a repeat expr hack, or it doesnt and is a normal anon const).
This should only affect unstable code as we handle repeat exprs specially and those are the only kinds of type system consts that are allowed to make use of generic parameters.
Fixes#133066Fixes#133199Fixes#136894Fixes#137813
r? compiler-errors
HIR ty lowering: Clean up & refactor the lowering of type-relative paths
While rebasing #126651 I realized that HIR ty lowering could benefit from some *spring cleaning* now that it's been extended to handle RTN and mGCA paths.
More seriously, similar to my merged PR #118668 which unified the handling of all *associated item constraints* (assoc ty, const (ACE) & fn (RTN)), this PR (commit 695fcf517d) partially[^1] deduplicates the resolution code for all *type-relative paths* (assoc ty, const (mGCA) & fn (RTN)).
**Why**? DRY'ing that part of the code means PR #126651 will automatically support RTN paths like `Ty::AssocTy::assoc_fn(..)` and it also implies shared diagnostic code and thus better diagnostics for RTN.
---
The other commits represent cleanups, renamings, moves. More notably, I've renamed path lowering methods to be a lot more descriptive, so ones lowering `QPath(Resolved)` paths now have `_resolved_` in their name and ones lowering `QPath(TypeRelative)` paths now have `_type_relative_` in their name. This should make it stupidly obvious what their purpose is.
---
Best reviewed commit by commit. The changes are close to trivial but the diff might make it look hairier.
r? compiler-errors
[^1]: Sadly, I couldn't unify as much compared to the other PR without introducing unnecessary `unreachable!()`s or rendering the code otherwise illegible with flags and micro helper traits.
