2017-06-10 14:19:40 -05:00
|
|
|
error[E0609]: no field `zz` on type `Foo`
|
2016-09-28 04:27:23 -05:00
|
|
|
--> $DIR/issue-36798_unknown_field.rs:17:7
|
|
|
|
|
|
|
2018-02-22 18:42:32 -06:00
|
|
|
LL | f.zz; //~ ERROR no field
|
2016-09-28 04:27:23 -05:00
|
|
|
| ^^ unknown field
|
field does not exist error: note fields if Levenshtein suggestion fails
When trying to access or initialize a nonexistent field, if we can't infer what
field was meant (by virtue of the purported field in the source being a small
Levenshtein distance away from an actual field, suggestive of a typo), issue a
note listing all the available fields. To reduce terminal clutter, we don't
issue the note when we have a `find_best_match_for_name` Levenshtein
suggestion: the suggestion is probably right.
The third argument of the call to `find_best_match_for_name` is changed to
`None`, accepting the default maximum Levenshtein distance of one-third of the
identifier supplied for correction. The previous value of `Some(name.len())`
was overzealous, inappropriately very Levenshtein-distant suggestions when the
attempted field access could not plausibly be a mere typo. For example, if a
struct has fields `mule` and `phone`, but I type `.donkey`, I'd rather the
error have a note listing that the available fields are, in fact, `mule` and
`phone` (which is the behavior induced by this patch) rather than the error
asking "did you mean `phone`?" (which is the behavior on master). The "only
find fits with at least one matching letter" comment was accurate when it was
first introduced in 09d992471 (January 2015), but is a vicious lie in its
present context before a call to `find_best_match_for_name` and must be
destroyed (replacing every letter is a Levenshtein distance of name.len()).
The present author claims that this suffices to resolve #42599.
2017-07-23 15:46:09 -05:00
|
|
|
|
|
2017-07-31 02:31:32 -05:00
|
|
|
= note: available fields are: `bar`
|
2016-09-28 04:27:23 -05:00
|
|
|
|
2017-07-02 05:49:30 -05:00
|
|
|
error: aborting due to previous error
|
2016-09-28 04:27:23 -05:00
|
|
|
|
2018-02-19 14:40:25 -06:00
|
|
|
If you want more information on this error, try using "rustc --explain E0609"
|
