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`
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
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>`.
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.
Only use implied bounds hack if bevy, and use deeply normalize in implied bounds hack
Consolidates the implied bounds computation mode into a single function, which deeply normalizes, and if it's in **compat** mode (for bevy), it extracts outlives bounds from the infcx.
Previously, we were using the implied bounds compat mode in two cases:
1. During WF, if it detects `ParamSet`
2. EVERYWHERE ELSE (lol) -- e.g. borrowck, predicate entailment, etc.
While I think this is fine, and the net effect was just that we emitted fewer diagnostics, it makes me uncomfortable that all crates were using the supposed "compat" code.
Fixes#137767
Perform deeper compiletest path normalization for `$TEST_BUILD_DIR` to account for compare-mode/debugger cases, and normalize long type file filename hashes
Fixes#136510.
### Summary
- Whereas previously `$TEST_BUILD_DIR` is a normalization of `/path/to/build/test/<test_suite_name>/`, we now more deeply normalize. `$TEST_BUILD_DIR` now becomes a normalization of `/path/to/build/test/<test_suite_name>/<subdirs>/$name.$revision.$compare_mode.$debugger/` to normalize away path name differences when `--compare-mode` and/or `--debugger` are specified.
- We also centralize the normalization of long type name hashes
cf. https://github.com/rust-lang/rust/pull/136328#discussion_r1936760908.
### Review advice
- Best reviewed commit-by-commit.
- Split into 3 commits:
- **Commit 1**: compiletest changes to have `$TEST_BUILD_DIR` more deeply normalize.
- **Commit 2**: remove per-test hacks for long type path hash normalizations, and rebless tests *specifically* affected by that.
- **Commit 3**: rebless other tests that were changed as a side-effect of deeper `$TEST_BUILD_DIR` normalizations.
**Commit 2** is created via first finding tests that try to perform long type file hash normalizations on an ad hoc, per-test basis:
```
rg --no-ignore -l --no-ignore -F -e "long-type" tests/ui/**/*.rs
```
<details>
<summary>Tests with ad hoc long-type hash normalizations</summary>
```
tests/ui/type_length_limit.rs
tests/ui/traits/on_unimplemented_long_types.rs
tests/ui/regions/issue-102374.rs
tests/ui/recursion/recursion.rs
tests/ui/recursion/issue-83150.rs
tests/ui/recursion/issue-23122-2.rs
tests/ui/methods/inherent-bound-in-probe.rs
tests/ui/issues/issue-67552.rs
tests/ui/issues/issue-37311-type-length-limit/issue-37311.rs
tests/ui/issues/issue-20413.rs
tests/ui/issues/issue-8727.rs
tests/ui/infinite/infinite-instantiation.rs
tests/ui/infinite/infinite-instantiation-struct-tail-ice-114484.rs
tests/ui/higher-ranked/trait-bounds/hrtb-doesnt-borrow-self-1.rs
tests/ui/higher-ranked/trait-bounds/hrtb-doesnt-borrow-self-2.rs
tests/ui/higher-ranked/trait-bounds/hang-on-deeply-nested-dyn.rs
tests/ui/error-codes/E0275.rs
tests/ui/diagnostic-width/secondary-label-with-long-type.rs
tests/ui/diagnostic-width/long-e0277.rs
tests/ui/diagnostic-width/non-copy-type-moved.rs
tests/ui/diagnostic-width/long-E0308.rs
tests/ui/diagnostic-width/E0271.rs
tests/ui/diagnostic-width/binop.rs
```
</details>
These ad hoc normalizations were removed, and they are reblessed.
r? `````@lqd`````
Make `ptr_cast_add_auto_to_object` lint into hard error
In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds. This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting.
We considered just making this a hard error, but opted against it at that time due to breakage found by crater. This breakage was mostly due to the `anymap` crate which has been a persistent problem for us.
It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`. So let's see about making a hard error of this.
r? ghost
cc ```@adetaylor``` ```@Darksonn``` ```@BoxyUwU``` ```@RalfJung``` ```@compiler-errors``` ```@oli-obk``` ```@WaffleLapkin```
Related:
- https://github.com/rust-lang/rust/pull/135881
- https://github.com/rust-lang/rust/issues/136702
- https://github.com/rust-lang/rust/pull/136776
Tracking:
- https://github.com/rust-lang/rust/issues/127323
- https://github.com/rust-lang/rust/issues/44874
- https://github.com/rust-lang/rust/issues/123430
Pretty-print `#[deprecated]` attribute in HIR.
Pretty-print `#[deprecated]` attribute in a form closer to how it might appear in Rust source code, rather than using a `Debug`-like representation.
Consider the following Rust code:
```rust
#[deprecated]
pub struct PlainDeprecated;
#[deprecated = "here's why this is deprecated"]
pub struct DirectNote;
#[deprecated(since = "1.2.3", note = "here's why this is deprecated")]
pub struct SinceAndNote;
```
Here's the previous output:
```
#[attr="Deprecation{deprecation: Deprecation{since: Unspecifiednote:
suggestion: }span: }")]
struct PlainDeprecated;
#[attr="Deprecation{deprecation: Deprecation{since: Unspecifiednote:
here's why this is deprecatedsuggestion: }span: }")]
struct DirectNote;
#[attr="Deprecation{deprecation: Deprecation{since: NonStandard(1.2.3)note:
here's why this is deprecatedsuggestion: }span: }")]
struct SinceAndNote;
```
Here's the new output:
```rust
#[deprecated]
struct PlainDeprecated;
#[deprecated = "here's why this is deprecated"]
struct DirectNote;
#[deprecated(since = "1.2.3", note = "here's why this is deprecated"]
struct SinceAndNote;
```
Also includes a test for `#[diagnostic::(..)]` attributes, though their behavior is not changed here. I already wrote the test, so I figured it probably won't hurt to have it.
Related to discussion in #137645.
r? `@jdonszelmann`
Allow struct field default values to reference struct's generics
Right now, the default field value feature (https://github.com/rust-lang/rust/issues/132162) lowers anon consts whose types may reference ADT params that the const doesn't inherit.
This PR fixes this, so that these defaults can reference ADTs' generics, and sets the `generics_of` parenting up correctly.
There doesn't seem to be a good reason not to support this, since the anon const has a well-defined type from the field, and the anon const doesn't interact with the type system like generic parameter defaults do.
r? `````@boxyuwu````` or reassign
I could also make this into an error if this seems problematic (https://github.com/rust-lang/rust/compare/master...compiler-errors:rust:default-field-value-implicit-param?expand=1)...... but I'd rather make this work and register an open question on the tracking issue about validating that this is well-vetted.
Fixes#137896
Do not recover missing lifetime with random in-scope lifetime
Suppresses a ton of stray errors, since this recovery doesn't really make sense anymore now that we have a dedicated `ReError` kind.
r? oli-obk or reassign
mgca: Lower all const paths as `ConstArgKind::Path`
When `#![feature(min_generic_const_args)]` is enabled, we now lower all
const paths in generic arg position to `hir::ConstArgKind::Path`. We
then lower assoc const paths to `ty::ConstKind::Unevaluated` since we
can no longer use the anon const expression lowering machinery. In the
process of implementing this, I factored out `hir_ty_lowering` code that
is now shared between lowering assoc types and assoc consts.
This PR also introduces a `#[type_const]` attribute for trait assoc
consts that are allowed as const args. However, we still need to
implement code to check that assoc const definitions satisfy
`#[type_const]` if present (basically is it a const path or a
monomorphic anon const).
r? `@BoxyUwU`
