mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
e72c45ad98
rust/tests/ui/did_you_mean/issue-42599_available_fields_note.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

33 lines
1.6 KiB
Plaintext
Raw Normal View History

pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 02:40:56 -05:00
error[E0560]: struct `Demo` has no field named `inocently_mispellable`
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-42599_available_fields_note.rs:16:39
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
|
Fix rebase
2018-02-24 17:59:34 -06:00
LL | Self { secret_integer: 2, inocently_mispellable: () }
use structured suggestions for nonexistent fields
2018-12-20 17:10:46 -06:00
| ^^^^^^^^^^^^^^^^^^^^^ help: a field with a similar name exists: `innocently_misspellable`
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
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 02:40:56 -05:00
error[E0560]: struct `Demo` has no field named `egregiously_nonexistent_field`
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-42599_available_fields_note.rs:21:39
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
|
Fix rebase
2018-02-24 17:59:34 -06:00
LL | Self { secret_integer: 3, egregiously_nonexistent_field: () }
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 02:40:56 -05:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Demo` does not have this 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
|
limit and delimit available fields in note Also, don't show the note if no fields are available (usually due to privacy).
2017-07-31 02:31:32 -05:00
= note: available fields are: `favorite_integer`, `secret_integer`, `innocently_misspellable`, `another_field`, `yet_another_field` ... and 2 others
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
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 02:40:56 -05:00
error[E0609]: no field `inocently_mispellable` on type `Demo`
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-42599_available_fields_note.rs:32:41
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
|
Update UI tests
2018-02-22 18:42:32 -06:00
LL | let innocent_field_misaccess = demo.inocently_mispellable;
use structured suggestions for nonexistent fields
2018-12-20 17:10:46 -06:00
| ^^^^^^^^^^^^^^^^^^^^^ help: a field with a similar name exists: `innocently_misspellable`
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
pretty: trim paths of unique symbols If a symbol name can only be imported from one place for a type, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path and print only the name. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable anywhere. This adds a new '-Z trim-diagnostic-paths=false' option to control this feature. On the good path, with no diagnosis printed, we should try to avoid issuing this query, so we need to prevent trimmed_def_paths query on several cases. This change also relies on a previous commit that differentiates between `Debug` and `Display` on various rustc types, where the latter is trimmed and presented to the user and the former is not.
2020-09-02 02:40:56 -05:00
error[E0609]: no field `egregiously_nonexistent_field` on type `Demo`
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/issue-42599_available_fields_note.rs:35:42
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
|
Update UI tests
2018-02-22 18:42:32 -06:00
LL | let egregious_field_misaccess = demo.egregiously_nonexistent_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
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unknown field
|
limit and delimit available fields in note Also, don't show the note if no fields are available (usually due to privacy).
2017-07-31 02:31:32 -05:00
= note: available fields are: `favorite_integer`, `innocently_misspellable`
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
error: aborting due to 4 previous errors
hide `--explain` hint if error has no extended info
2019-04-17 12:26:38 -05:00
Some errors have detailed explanations: E0560, E0609.
update tests
2018-03-03 08:59:40 -06:00
For more information about an error, try `rustc --explain E0560`.
Reference in New Issue Copy Permalink