-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggest correct enum variant on typo #56204
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -36,8 +36,9 @@ use lint; | |
|
||
use std::iter; | ||
use syntax::ast; | ||
use syntax::ptr::P; | ||
use syntax::feature_gate::{GateIssue, emit_feature_err}; | ||
use syntax::ptr::P; | ||
use syntax::util::lev_distance::find_best_match_for_name; | ||
use syntax_pos::{DUMMY_SP, Span, MultiSpan}; | ||
|
||
pub trait AstConv<'gcx, 'tcx> { | ||
|
@@ -1303,6 +1304,32 @@ impl<'o, 'gcx: 'tcx, 'tcx> dyn AstConv<'gcx, 'tcx>+'o { | |
Err(ErrorReported) => return (tcx.types.err, Def::Err), | ||
} | ||
} | ||
(&ty::Adt(adt_def, _substs), Def::Enum(_did)) => { | ||
let ty_str = ty.to_string(); | ||
// Incorrect enum variant | ||
let mut err = tcx.sess.struct_span_err( | ||
span, | ||
&format!("no variant `{}` on enum `{}`", &assoc_name.as_str(), ty_str), | ||
); | ||
// Check if it was a typo | ||
let input = adt_def.variants.iter().map(|variant| &variant.name); | ||
if let Some(suggested_name) = find_best_match_for_name( | ||
input, | ||
&assoc_name.as_str(), | ||
None, | ||
) { | ||
err.span_suggestion_with_applicability( | ||
span, | ||
"did you mean", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The I remember you said something once about doing a grand error-message style-and-consistency copyediting session, at which time we might come back and rephrase this and others? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's what I'm thinking yes. I don't like it either, but it is the wording used for this family of errors. I'd really like to come up with a wording that would work equally well for |
||
format!("{}::{}", ty_str, suggested_name.to_string()), | ||
Applicability::MaybeIncorrect, | ||
); | ||
} else { | ||
err.span_label(span, "unknown variant"); | ||
} | ||
err.emit(); | ||
return (tcx.types.err, Def::Err); | ||
} | ||
_ => { | ||
// Don't print TyErr to the user. | ||
if !ty.references_error() { | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,9 +1,8 @@ | ||
error[E0223]: ambiguous associated type | ||
error: no variant `B` on enum `S` | ||
--> $DIR/issue-34209.rs:17:9 | ||
| | ||
LL | S::B{ } => { }, | ||
| ^^^^ help: use fully-qualified syntax: `<S as Trait>::B` | ||
LL | S::B { } => { }, | ||
| ^^^^ help: did you mean: `S::A` | ||
|
||
error: aborting due to previous error | ||
|
||
For more information about this error, try `rustc --explain E0223`. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
#[derive(Debug)] | ||
enum Shape { | ||
Square { size: i32 }, | ||
Circle { radius: i32 }, | ||
} | ||
|
||
struct S { | ||
x: usize, | ||
} | ||
|
||
fn main() { | ||
println!("My shape is {:?}", Shape::Squareee { size: 5}); | ||
println!("My shape is {:?}", Shape::Circl { size: 5}); | ||
println!("My shape is {:?}", Shape::Rombus{ size: 5}); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
error: no variant `Squareee` on enum `Shape` | ||
--> $DIR/suggest-variants.rs:12:34 | ||
| | ||
LL | println!("My shape is {:?}", Shape::Squareee { size: 5}); | ||
| ^^^^^^^^^^^^^^^ help: did you mean: `Shape::Square` | ||
|
||
error: no variant `Circl` on enum `Shape` | ||
--> $DIR/suggest-variants.rs:13:34 | ||
| | ||
LL | println!("My shape is {:?}", Shape::Circl { size: 5}); | ||
| ^^^^^^^^^^^^ help: did you mean: `Shape::Circle` | ||
|
||
error: no variant `Rombus` on enum `Shape` | ||
--> $DIR/suggest-variants.rs:14:34 | ||
| | ||
LL | println!("My shape is {:?}", Shape::Rombus{ size: 5}); | ||
| ^^^^^^^^^^^^^ unknown variant | ||
|
||
error: aborting due to 3 previous errors | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have criteria written down anywhere for which errors deserve a dedicated E0XXX code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My personal criteria has been when splitting existing errors to just continue what was there: create a new code when the existing one has one, don't bother when the existing doesn't, with the thinking of going back at a later time after the diagnostic has been seen in the wild for a bit. That being said, it'd probably be a good idea to require adding codes more aggressively than we do now. My only concern there would be when the error would be so all-encompassing that it's help text would be almost useless.