Move `yield` expressions behind their own feature gate
In order to make progress with the `iter!` macro (e.g. in #137725), we need `yield` expressions to be available without the `coroutines` feature. This PR moves `yield` to be guarded by the `yield_expr` feature so that we can stabilize that independently (or at least, concurrently with the `iter_macro` feature). Note that once `yield` is stable, it will still be an error to use `yield` expressions outside something like a generator or coroutine, and these features remain unstable.
r? `@oli-obk`
Use final path segment for diagnostic
Test changes should prove the effect of this PR; we want to mention the *function name* not the arbitrary first segment of the path.
Add timestamp to unstable feature usage metrics
part of https://github.com/rust-lang/rust/issues/129485
with this we should be able to temporarily enable metrics on docs.rs to gather a nice test dataset for the initial PoC dashboard
r? ```@estebank```
An inline asm terminator defines outputs along its target edges -- a
fallthrough target and labeled targets. Code generation implements this
by inserting code directly into the target blocks. This approach works
only if the target blocks don't have other predecessors.
Establish required invariant by extending existing code that breaks
critical edges before code generation.
Improve error message for `AsyncFn` trait failure for RPIT
Use a `WellFormedDerived` obligation cause to make sure we can turn an `AsyncFnKindHelper` trait goal into its parent `AsyncFn*` goal, then fix the logic for reporting `AsyncFn*` kind mismatches.
Best reviewed without whitespace.
Fixes#137905
r? oli-obk
Provide more context on resolve error caused from incorrect RTN
When encountering a resolve E0575 error for an associated method (when a type was expected), see if it could have been an intended return type notation bound.
```
error[E0575]: expected associated type, found associated function `Trait::method`
--> $DIR/bad-inputs-and-output.rs:31:36
|
LL | fn foo_qualified<T: Trait>() where <T as Trait>::method(i32): Send {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^ not a associated type
|
help: you might have meant to use the return type notation syntax
|
LL - fn foo_qualified<T: Trait>() where <T as Trait>::method(i32): Send {}
LL + fn foo_qualified<T: Trait>() where T::method(..): Send {}
|
```
Built on top of #137824, only second commit is relevant for review.
r? ````````@compiler-errors````````
fix usage of ty decl macro fragments in attributes
See the test case. Due to one missing code path (and also the changes in #137517), using $ty or other specific fragments as part of an attr wouldn't work. $tt used to work since it wouldn't be parsed anywhere along the way.
Closes#137662
Add DWARF test case for non-C-like `repr128` enums
LLVM 20 fixes DWARF debuginfo for non-C-like 128-bit enums: this PR adds a test case to the `repr128-dwarf` test to ensure that LLVM doesn't regress in the future.
Tracking issue: #56071
Try to point of macro expansion from resolver and method errors if it involves macro var
In the case that a macro caller passes an identifier into a macro generating a path or method expression, point out that identifier in the context of the *macro* so it's a bit more clear how the macro is involved in causing the error.
r? ``````````@estebank`````````` or reassign
Remove `MaybeForgetReturn` suggestion
#115196 implemented a suggestion to add a missing `return` when there is an ambiguity error, when that ambiguity error could be constrained by the return type of the function.
I initially reviewed it and thought it could be useful; however, looking back at that code now, I feel like it's a bit too much of a hack to be worth keeping around in typeck, especially given how rare it's expected to fire in practice. This is especially true because it depends on `StashKey::MaybeForgetReturn`, which is only stashed when we have *Sized* obligation ambiguity errors. Let's remove it for now.
I'd like to note that it's basically impossible to get this suggestion to apply in its current state except for what I'd consider somewhat artificial examples, involving no generic trait bounds. For example, it's not triggered for:
```rust
struct W<T>(T);
fn bar<T: Default>() -> W<T> { todo!() }
fn foo() -> W<i32> {
if true {
bar();
}
W(0)
}
```
Nor is it triggered for:
```
fn foo() -> i32 {
if true {
Default::default();
}
0
}
```
It's basically only triggered iff there's only one ambiguity error on the type, which is `Sized`.
Generally, suggesting something that affects control flow is a pretty dramatic suggestion; therefore, both the accuracy and precision of this diagnostic should be pretty high.
One other, somewhat unrelated observation is that this might be using stashed diagnostics incorrectly (or at least unnecessarily). Stashed diagnostics are used when error detection is fragmented over several major stages of the compiler, like a parse or resolver error which later can be recovered in typeck. However, this one is a bit different since it is fully handled within typeck -- perhaps that suggests that if this were to be reimplemented, it wouldn't need to be so complicated of an implementation.
Pattern types: Avoid having to handle an Option for range ends in the type system or the HIR
Instead,
1. during hir_ty_lowering, we now generate constants for the min/max when the range doesn't have a start/end specified.
2. in a later commit we generate those constants during ast lowering, simplifying everything further by not having to handle the range end inclusivity anymore in the type system (and thus avoiding any issues of `0..5` being different from `0..=4`
I think it makes all the type system code simpler, and the cost of the extra `ConstKind::Value` processing seems negligible.
r? `@BoxyUwU`
cc `@joshtriplett` `@scottmcm`
Implement `&pin const self` and `&pin mut self` sugars
This PR implements part of #130494.
It introduces the sugars `&pin const self` and `&pin mut self` for `self: Pin<&Self>` and `self: Pin<&mut Self>`.
Inline `FnOnce`/`FnMut`/`Fn` shims once again
This PR fixes the argument checking for `extern "rust-call"` ABI functions with a spread arg, which do no expect their arguments to be exploded from a tuple like closures do.
Secondly, it removes the hack that prevented them from being inlined. This results in more work done by the compiler, but it does end up allowing us to inline functions we didn't before.
Fixes#137901
compiler: add `ExternAbi::is_rustic_abi`
Various parts of the compiler were hand-rolling this extremely simple check that is nonetheless easy to get wrong as the compiler evolves over time. Discourage them from being so "original" again by replacing it with a single implementation on the type that represents these ABIs. This simplifies a surprising amount of code as a result.
Also fixes#132981, an ICE that emerged due to other checks being made stricter.
