Make opaque types regular HIR nodes
Having opaque types as HIR owner introduces all sorts of complications. This PR proposes to make them regular HIR nodes instead.
I haven't gone through all the test changes yet, so there may be a few surprises.
Many thanks to `@camelid` for the first draft.
Fixes https://github.com/rust-lang/rust/issues/129023Fixes#129099Fixes#125843Fixes#119716Fixes#121422
Account for `impl Trait {` when `impl Trait for Type {` was intended
On editions where bare traits are never allowed, detect if the user has written `impl Trait` with no type, silence any dyn-compatibility errors, and provide a structured suggestion for the potentially missing type:
```
error[E0782]: trait objects must include the `dyn` keyword
--> $DIR/missing-for-type-in-impl.rs:8:6
|
LL | impl Foo<i64> {
| ^^^^^^^^
|
help: add `dyn` keyword before this trait
|
LL | impl dyn Foo<i64> {
| +++
help: you might have intended to implement this trait for a given type
|
LL | impl Foo<i64> for /* Type */ {
| ++++++++++++++
```
CC #131051.
Fix needless_lifetimes in stable_mir
Hi,
This PR fixes the following clippy warning in stable_mir
```
warning: the following explicit lifetimes could be elided: 'a
--> compiler/stable_mir/src/mir/visit.rs:79:30
|
79 | fn visit_projection_elem<'a>(
| ^^
80 | &mut self,
81 | place_ref: PlaceRef<'a>,
| ^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
= note: `#[warn(clippy::needless_lifetimes)]` on by default
help: elide the lifetimes
|
79 ~ fn visit_projection_elem(
80 | &mut self,
81 ~ place_ref: PlaceRef<'_>,
|
```
Best regards,
Michal
Add support for reborrowing pinned method receivers
This builds on #130526 to add pinned reborrowing for method receivers. This enables the folllowing examples to work:
```rust
#![feature(pin_ergonomics)]
#![allow(incomplete_features)]
use std::pin::Pin;
pub struct Foo;
impl Foo {
fn foo(self: Pin<&mut Self>) {
}
fn baz(self: Pin<&Self>) {
}
}
pub fn bar(x: Pin<&mut Foo>) {
x.foo();
x.foo();
x.baz(); // Pin<&mut Foo> is downgraded to Pin<&Foo>
}
pub fn baaz(x: Pin<&Foo>) {
x.baz();
x.baz();
}
```
This PR includes the original one, which is currently in the commit queue, but the only code changes are in the latest commit (d3c53aaa5c6fcb1018c58d229bc5d92202fa6880).
#130494
r? `@compiler-errors`
Check elaborated projections from dyn don't mention unconstrained late bound lifetimes
Check that the projections that are *not* explicitly written but which we deduce from elaborating the principal of a `dyn` *also* do not reference unconstrained late-bound lifetimes, just like the ones that the user writes by hand.
That is to say, given:
```
trait Foo<T>: Bar<Assoc = T> {}
trait Bar {
type Assoc;
}
```
The type `dyn for<'a> Foo<&'a T>` (basically) elaborates to `dyn for<'a> Foo<&'a T> + for<'a> Bar<Assoc = &'a T>`[^1]. However, the `Bar` projection predicate is not well-formed, since `'a` must show up in the trait's arguments to be referenced in the term of a projection. We must error in this situation[^well], or else `dyn for<'a> Foo<&'a T>` is unsound.
We already detect this for user-written projections during HIR->rustc_middle conversion, so this largely replicates that logic using the helper functions that were already conveniently defined.
---
I'm cratering this first to see the fallout; if it's minimal or zero, then let's land it as-is. If not, the way that this is implemented is very conducive to an FCW.
---
Fixes#130347
[^1]: We don't actually elaborate it like that in rustc; we only keep the principal trait ref `Foo<&'a T>` and the projection part of `Bar<Assoc = ...>`, but it's useful to be a bit verbose here for the purpose of explaining the issue.
[^well]: Well, we could also make `dyn for<'a> Foo<&'a T>` *not* implement `for<'a> Bar<Assoc = &'a T>`, but this is inconsistent with the case where the user writes `Assoc = ...` in the type itself, and it overly complicates the implementation of trait objects' built-in impls.
Update cargo
17 commits in 80d82ca22abbee5fb7b51fa1abeb1ae34e99e88a..ad074abe3a18ce8444c06f962ceecfd056acfc73
2024-09-27 17:56:01 +0000 to 2024-10-04 18:18:15 +0000
- test: Remove the last of our custom json assertions (rust-lang/cargo#14576)
- docs(ref): Expand on MSRV (rust-lang/cargo#14636)
- docs: Minor re-grouping of pages (rust-lang/cargo#14620)
- docs(ref): Highleft whats left for msrv-policy (rust-lang/cargo#14638)
- Fix `cargo:version_number` - has only one `:` (rust-lang/cargo#14637)
- docs: Declare support level for each crate in our Charter / docs (rust-lang/cargo#14600)
- chore(deps): update tar to 0.4.42 (rust-lang/cargo#14632)
- docs(charter): Declare new Intentional Artifacts as 'small' changes (rust-lang/cargo#14599)
- fix: Remove implicit feature removal (rust-lang/cargo#14630)
- docs(config): make `--config <PATH>` more prominent (rust-lang/cargo#14631)
- chore(deps): update rust crate unicode-width to 0.2.0 (rust-lang/cargo#14624)
- chore(deps): update embarkstudios/cargo-deny-action action to v2 (rust-lang/cargo#14628)
- docs(ref): Clean up language for `package.rust-version` (rust-lang/cargo#14619)
- docs: clarify `target.'cfg(...)'` doesnt respect cfg from build script (rust-lang/cargo#14312)
- test: relax compiler panic assertions (rust-lang/cargo#14618)
- refactor(compiler): zero-copy deserialization when possible (rust-lang/cargo#14608)
- test: add support for features in the sat resolver (rust-lang/cargo#14583)
On editions where bare traits are never allowed, detect if the user has
written `impl Trait` with no type, silence any dyn-compatibility errors,
and provide a structured suggestion for the potentially missing type:
```
error[E0782]: trait objects must include the `dyn` keyword
--> $DIR/missing-for-type-in-impl.rs:8:6
|
LL | impl Foo<i64> {
| ^^^^^^^^
|
help: add `dyn` keyword before this trait
|
LL | impl dyn Foo<i64> {
| +++
help: you might have intended to implement this trait for a given type
|
LL | impl Foo<i64> for /* Type */ {
| ++++++++++++++
```
Fix `target_abi` in `sparc-unknown-none-elf`
This was previously set to `target_abi = "elf"`, but `elf` is not used elsewhere as a target ABI (even though there's many targets that have it in their name), so I've removed it.
CC target maintainer ``@jonathanpallant,`` what do you think about this?
``@rustbot`` label O-SPARC
