…lcnr

Don't assume traits used as type are trait objs in 2021 edition

Fixes rust-lang#127548

When you use a trait as a type, the compiler automatically assumes you meant to use a trait object, which is not always the case.
This PR fixes the bug where you don't need a trait object, so the error message was changed to:
```
error[E0782]: expected a type, found a trait
```
Also fixes some ICEs:
Fixes rust-lang#120241
Fixes rust-lang#120482
Fixes rust-lang#125512

…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#130870 (Add suggestion for removing invalid path sep `::` in fn def)
 - rust-lang#131233 (std: fix stdout-before-main)
 - rust-lang#131239 (Don't assume traits used as type are trait objs in 2021 edition)
 - rust-lang#131277 (Handle `clippy` cases of `rustc::potential_query_instability` lint)
 - rust-lang#131567 (Emit an error for unstable attributes that reference already stable features)
 - rust-lang#131585 (compiletest: Remove the one thing that was checking a directive's `original_line`)
 - rust-lang#131590 (yeet some clones)
 - rust-lang#131597 (Take a display name for `tool_check_step!`)

r? `@ghost`
`@rustbot` modify labels: rollup

…lcnr

Don't assume traits used as type are trait objs in 2021 edition

Fixes rust-lang#127548

When you use a trait as a type, the compiler automatically assumes you meant to use a trait object, which is not always the case.
This PR fixes the bug where you don't need a trait object, so the error message was changed to:
```
error[E0782]: expected a type, found a trait
```
Also fixes some ICEs:
Fixes rust-lang#120241
Fixes rust-lang#120482
Fixes rust-lang#125512

…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#128784 (Check ABI target compatibility for function pointers)
 - rust-lang#130965 (make `Step` doc-comments more clear)
 - rust-lang#131239 (Don't assume traits used as type are trait objs in 2021 edition)
 - rust-lang#131277 (Handle `clippy` cases of `rustc::potential_query_instability` lint)
 - rust-lang#131503 (More clearly document Stdin::read_line)
 - rust-lang#131567 (Emit an error for unstable attributes that reference already stable features)
 - rust-lang#131599 (Shallowly match opaque key in storage)
 - rust-lang#131617 (remove const_cow_is_borrowed feature gate)

Failed merges:

 - rust-lang#131616 (merge const_ipv4 / const_ipv6 feature gate into 'ip' feature gate)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#131239 - VulnBandit:trait-vulnerability, r=lcnr

Don't assume traits used as type are trait objs in 2021 edition

Fixes rust-lang#127548

When you use a trait as a type, the compiler automatically assumes you meant to use a trait object, which is not always the case.
This PR fixes the bug where you don't need a trait object, so the error message was changed to:
```
error[E0782]: expected a type, found a trait
```
Also fixes some ICEs:
Fixes rust-lang#120241
Fixes rust-lang#120482
Fixes rust-lang#125512

…=davidtwco

Improve parse errors for stray lifetimes in type position

While technically & syntactically speaking lifetimes do begin[^1] types in type contexts (this essentially excludes generic argument lists) and require a following `+` to form a complete type (`'a +` denotes a bare trait object type), the likelihood that a user meant to write a lifetime-prefixed bare trait object type in *modern* editions (Rust ≥2021) when placing a lifetime into a type context is incredibly low (they would need to add at least three tokens to turn it into a *semantically* well-formed TOT: `'a` → `dyn 'a + Trait`).

Therefore let's *lie* in modern editions (just like in PR rust-lang#131239, a precedent if you will) by stating "*expected type, found lifetime*" in such cases which is a lot more a approachable, digestible and friendly compared to "*lifetime in trait object type must be followed by `+`*" (as added in PR rust-lang#69760).

I've also added recovery for "ampersand-less" reference types (e.g., `'a ()`, `'a mut Ty`) in modern editions because it was trivial to do and I think it's not unlikely to occur in practice.

Fixes rust-lang#133413.

[^1]: For example, in the context of decl macros, this implies that a lone `'a` always matches syntax fragment `ty` ("even if" there's a later macro matcher expecting syntax fragment `lifetime`). Rephrased, lifetimes (in type contexts) *commit* to the type parser.

Rollup merge of rust-lang#139854 - fmease:modern-diag-for-lt-in-ty, r=davidtwco

Improve parse errors for stray lifetimes in type position

While technically & syntactically speaking lifetimes do begin[^1] types in type contexts (this essentially excludes generic argument lists) and require a following `+` to form a complete type (`'a +` denotes a bare trait object type), the likelihood that a user meant to write a lifetime-prefixed bare trait object type in *modern* editions (Rust ≥2021) when placing a lifetime into a type context is incredibly low (they would need to add at least three tokens to turn it into a *semantically* well-formed TOT: `'a` → `dyn 'a + Trait`).

Therefore let's *lie* in modern editions (just like in PR rust-lang#131239, a precedent if you will) by stating "*expected type, found lifetime*" in such cases which is a lot more a approachable, digestible and friendly compared to "*lifetime in trait object type must be followed by `+`*" (as added in PR rust-lang#69760).

I've also added recovery for "ampersand-less" reference types (e.g., `'a ()`, `'a mut Ty`) in modern editions because it was trivial to do and I think it's not unlikely to occur in practice.

Fixes rust-lang#133413.

[^1]: For example, in the context of decl macros, this implies that a lone `'a` always matches syntax fragment `ty` ("even if" there's a later macro matcher expecting syntax fragment `lifetime`). Rephrased, lifetimes (in type contexts) *commit* to the type parser.

Improve parse errors for stray lifetimes in type position

While technically & syntactically speaking lifetimes do begin[^1] types in type contexts (this essentially excludes generic argument lists) and require a following `+` to form a complete type (`'a +` denotes a bare trait object type), the likelihood that a user meant to write a lifetime-prefixed bare trait object type in *modern* editions (Rust ≥2021) when placing a lifetime into a type context is incredibly low (they would need to add at least three tokens to turn it into a *semantically* well-formed TOT: `'a` → `dyn 'a + Trait`).

Therefore let's *lie* in modern editions (just like in PR rust-lang/rust#131239, a precedent if you will) by stating "*expected type, found lifetime*" in such cases which is a lot more a approachable, digestible and friendly compared to "*lifetime in trait object type must be followed by `+`*" (as added in PR rust-lang/rust#69760).

I've also added recovery for "ampersand-less" reference types (e.g., `'a ()`, `'a mut Ty`) in modern editions because it was trivial to do and I think it's not unlikely to occur in practice.

Fixes #133413.

[^1]: For example, in the context of decl macros, this implies that a lone `'a` always matches syntax fragment `ty` ("even if" there's a later macro matcher expecting syntax fragment `lifetime`). Rephrased, lifetimes (in type contexts) *commit* to the type parser.