Rollup of 11 pull requests
Successful merges:
- #120577 (Stabilize slice_split_at_unchecked)
- #122698 (Cancel `cargo update` job if there's no updates)
- #122780 (Rename `hir::Local` into `hir::LetStmt`)
- #122915 (Delay a bug if no RPITITs were found)
- #122916 (docs(sync): normalize dot in fn summaries)
- #122921 (Enable more mir-opt tests in debug builds)
- #122922 (-Zprint-type-sizes: print the types of awaitees and unnamed coroutine locals.)
- #122927 (Change an ICE regression test to use the original reproducer)
- #122930 (add panic location to 'panicked while processing panic')
- #122931 (Fix some typos in the pin.rs)
- #122933 (tag_for_variant follow-ups)
r? `@ghost`
`@rustbot` modify labels: rollup
Change an ICE regression test to use the original reproducer
The ICE was fixed in PR https://github.com/rust-lang/rust/pull/122370, but the test used a different reproducer than the one originally reported. This PR changes it to the original one, giving us more confidence that the fix works.
Fixes#122199
-Zprint-type-sizes: print the types of awaitees and unnamed coroutine locals.
This should assist comprehending the size of coroutines. In particular, whenever a future is suspended while awaiting another future, the latter is given the special name `__awaitee`, and now the type of the awaited future will be printed, allowing identifying caller/callee — er, I mean, poller/pollee — relationships.
It would be possible to include the type name in more cases, but I thought that that might be overly verbose (`print-type-sizes` is already a lot of text) and ordinary named fields or variables are easier for readers to discover the types of.
This change will also synergize with my other PR #122923 which changes type printing to print the path of the `async fn` instead of the span.
Implementation note: I'm not sure if `Symbol::intern` is appropriate for this application, but it was the obvious way to not have to remove the `Copy` implementation from `FieldInfo`, or add a `'tcx` lifetime, while avoiding keeping a lot of possibly redundant strings in memory. I don't know what the proper tradeoff to make here is (though presumably it is not too important for a `-Z` debugging option).
Rename `hir::Local` into `hir::LetStmt`
Follow-up of #122776.
As discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Improve.20naming.20of.20.60ExprKind.3A.3ALet.60.3F).
I made this change into a separate PR because I'm less sure about this change as is. For example, we have `visit_local` and `LocalSource` items. Is it fine to keep these two as is (I supposed it is but I prefer to ask) or not? Having `Node::Local(LetStmt)` makes things more explicit but is it going too far?
r? ```@oli-obk```
Cancel `cargo update` job if there's no updates
Previously there were always updates so we didn't hit this. Since #122489, this job runs on a more frequent schedule and causes errors if there have been no changes in that timespan.
This led to a weird error on https://github.com/rust-lang/rust/pull/122646#issuecomment-2004339093 - because of this I've replaced the `exit 1`s here with `gh run cancel` so we don't have false 'failed' jobs in the logs.
Stabilize slice_split_at_unchecked
Greetings!
I took the opportunity, and I tried to stabilize the `slice_split_at_unchecked` feature. I followed the guidelines, and I hope everything was done correctly 🤞 .
Closes#76014
Let codegen decide when to `mem::swap` with immediates
Making `libcore` decide this is silly; the backend has so much better information about when it's a good idea.
Thus this PR introduces a new `typed_swap` intrinsic with a fallback body, and replaces that fallback implementation when swapping immediates or scalar pairs.
r? oli-obk
Replaces #111744, and means we'll never need more libs PRs like #111803 or #107140
Fix nix patching for LLVM 18
LLVM 18 now ships `libLLVM*.so.*`, so `.so` is not the sole extension anymore, which breaks the dylib detection. Oops! Adjust it to only search for `.so` somewhere.
fixes#122906
This should assist comprehending the size of coroutines.
In particular, whenever a future is suspended while awaiting another
future, the latter is given the special name `__awaitee`, and now the
type of the awaited future will be printed, allowing identifying
caller/callee — er, I mean, poller/pollee — relationships.
It would be possible to include the type name in more cases, but I
thought that that might be overly verbose (`print-type-sizes` is already
a lot of text) and ordinary named fields or variables are easier for
readers to discover the types of.
The dead_code lint was previously eroneously missing this dead code.
Since this lint bug has been fixed, the unused field need to be removed
or marked as `#[allow(dead_code)]`.
Given that this struct is deserialized without #[serde(deny_unknown_fields)]
it is ok to simply delete the never read fields.
Rollup of 8 pull requests
Successful merges:
- #114009 (compiler: allow transmute of ZST arrays with generics)
- #122195 (Note that the caller chooses a type for type param)
- #122651 (Suggest `_` for missing generic arguments in turbofish)
- #122784 (Add `tag_for_variant` query)
- #122839 (Split out `PredicatePolarity` from `ImplPolarity`)
- #122873 (Merge my contributor emails into one using mailmap)
- #122885 (Adjust better spastorino membership to triagebot's adhoc_groups)
- #122888 (add a couple more tests)
r? `@ghost`
`@rustbot` modify labels: rollup
LLVM 18 now ships `libLLVM*.so.*`, so `.so` is not the sole extension
anymore, which breaks the dylib detection. Oops! Adjust it to only
search for `.so` somewhere.
Remove `TypeAndMut` from `ty::RawPtr` variant, make it take `Ty` and `Mutability`
Pretty much mechanically converting `ty::RawPtr(ty::TypeAndMut { ty, mutbl })` to `ty::RawPtr(ty, mutbl)` and its fallout.
r? lcnr
cc rust-lang/types-team#124
Split out `PredicatePolarity` from `ImplPolarity`
Because having to deal with a third `Reservation` level in all the trait solver code is kind of weird.
r? `@lcnr` or `@oli-obk`
Add `tag_for_variant` query
This query allows for sharing code between `rustc_const_eval` and `rustc_transmutability`. It's a precursor to a PR I'm working on to entirely replace the bespoke layout computations in `rustc_transmutability`.
r? `@compiler-errors`
Suggest `_` for missing generic arguments in turbofish
The compiler may suggest unusable generic type names for missing generic arguments in an expression context:
```rust
fn main() {
(0..1).collect::<Vec>()
}
```
> help: add missing generic argument
>
> (0..1).collect::<Vec<T>>()
but `T` is not a valid name in this context, and this suggestion won't compile.
I've changed it to use `_` inside method calls (turbofish), so it will suggest `(0..1).collect::<Vec<_>>()` which _may_ compile.
It's possible that the suggested `_` will be ambiguous, but there is very extensive E0283 that will help resolve that, which is more helpful than a basic "cannot find type `T` in this scope" users would get otherwise.
Out of caution to limit scope of the change I've limited it to just turbofish, but I suspect `_` could be the better choice in more cases. Perhaps in all expressions?
Note that the caller chooses a type for type param
```
error[E0308]: mismatched types
--> $DIR/return-impl-trait.rs:23:5
|
LL | fn other_bounds<T>() -> T
| - -
| | |
| | expected `T` because of return type
| | help: consider using an impl return type: `impl Trait`
| expected this type parameter
...
LL | ()
| ^^ expected type parameter `T`, found `()`
|
= note: expected type parameter `T`
found unit type `()`
= note: the caller chooses the type of T which can be different from ()
```
Tried to see if "expected this type parameter" can be replaced, but that goes all the way to `rustc_infer` so seems not worth the effort and can affect other diagnostics.
Revives #112088 and #104755.
compiler: allow transmute of ZST arrays with generics
Extend the `SizeSkeleton` evaluator to shortcut zero-sized arrays, thus considering `[T; 0]` to have a compile-time fixed-size of 0.
The existing evaluator already deals with generic arrays under the feature-guard `transmute_const_generics`. However, it merely allows comparing fixed-size types with fixed-size types, and generic types with generic types. For generic types, it merely compares whether their arguments match (ordering them first). Even if their exact sizes are not known at compile time, it can ensure that they will eventually be the same.
This patch extends this by shortcutting the size-evaluation of zero sized arrays and thus allowing size comparisons of `()` with `[T; 0]`, where one contains generics and the other does not.
This code is guarded by `transmute_const_generics` (#109929), even though it is unclear whether it should be. However, this assumes that a separate stabilization PR is required to move this out of the feature guard.
Initially reported in #98104.
"Handle" calls to upstream monomorphizations in compiler_builtins
This is pretty cooked, but I think it works.
compiler-builtins has a long-standing problem that at link time, its rlib cannot contain any calls to `core`. And yet, in codegen we _love_ inserting calls to symbols in `core`, generally from various panic entrypoints.
I intend this PR to attack that problem as completely as possible. When we generate a function call, we now check if we are generating a function call from `compiler_builtins` and whether the callee is a function which was not lowered in the current crate, meaning we will have to link to it.
If those conditions are met, actually generating the call is asking for a linker error. So we don't. If the callee diverges, we lower to an abort with the same behavior as `core::intrinsics::abort`. If the callee does not diverge, we produce an error. This means that compiler-builtins can contain panics, but they'll SIGILL instead of panicking. I made non-diverging calls a compile error because I'm guessing that they'd mostly get into compiler-builtins by someone making a mistake while working on the crate, and compile errors are better than linker errors. We could turn such calls into aborts as well if that's preferred.
