Open
Description
Given
#![feature(more_qualified_paths)]
enum E { S { gotten: () } }
struct S { wanted: i32 }
trait O { type S; fn f(); }
impl O for E {
type S = S;
fn f() { // (A)
let _ = Self::S { wanted: 0 }; //~ ERROR variant `E::S` has no field named `wanted`
}
}
fn main() { // (B)
let _ = E::S { wanted: 0 }; //~ ERROR variant `E::S` has no field named `wanted`
}
Self::S
(A) / E::S
(B) resolves to the enum variant, not the associated type and thus
error[E0559]: variant `E::S` has no field named `wanted`
--> src/main.rs:10:27
|
10 | let _ = Self::S { wanted: 0 };
| ^^^^^^ `E::S` does not have this field
|
= note: available fields are: `gotten`
error[E0559]: variant `E::S` has no field named `wanted`
--> src/main.rs:15:20
|
15 | let _ = E::S { wanted: 0 };
| ^^^^^^ `E::S` does not have this field
|
= note: available fields are: `gotten`
Ideally, since (and only since) more_qualified_paths
is enabled, rustc would suggest qualifying Self::S
and E::S
via <Self as O>::S
and <E as O>::S
, respectively.
These might be quite annoying to diagnose due to the sheer number of possible symptoms (e.g., missing fields, extra fields, fields of wrong type). Since this input is a bit contrived, marking P-low.
Case (A) is reminiscent of #57644 but still distinct (however, do we want to do anything here?).
Metadata
Metadata
Assignees
Labels
Area: Messages for errors, warnings, and lintsDiagnostics: Adding a (structured) suggestion would increase the quality of the diagnostic.Diagnostics: An error or lint that doesn't give enough information about the problem at hand.`#![feature(more_qualified_paths)]`Low priorityRelevant to the compiler team, which will review and decide on the PR/issue.