method-probing machinery can false-positive #46459
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-diagnostics
Working group: Diagnostics
Comments
|
To hopefully make this slightly more concrete: on my branch, this led to us suggesting adding fn main() {
let x: usize = String::new();
}which does not work. |
TimNN
added
A-diagnostics
zackmdavis
added a commit
to zackmdavis/rust
that referenced
this issue
Jan 7, 2018
Previously, on a type mismatch (and if this wasn't preëmpted by a higher-priority suggestion), we would look for argumentless methods returning the expected type, and list them in a `help` note. This had two major shortcomings. Firstly, a lot of the suggestions didn't really make sense (if you used a &str where a String was expected, `.to_ascii_uppercase()` is probably not the solution you were hoping for). Secondly, we weren't generating suggestions from the most useful traits! We address the first problem with an internal `#[rustc_conversion_suggestion]` attribute meant to mark methods that keep the "same value" in the relevant sense, just converting the type. We address the second problem by making `FnCtxt.probe_for_return_type` pass the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe because grep reveals no other callers of `probe_for_return_type`. Also, structured suggestions are preferred (because they're pretty, but also for RLS and friends). Also also, we make the E0055 autoderef recursion limit error use the one-time-diagnostics set, because we can potentially hit the limit a lot during probing. (Without this, test/ui/did_you_mean/recursion_limit_deref.rs would report "aborting due to 51 errors"). Unfortunately, the trait probing is still not all one would hope for: at a minimum, we don't know how to rule out `into()` in cases where it wouldn't actually work, and we don't know how to rule in `.to_owned()` where it would. Issues rust-lang#46459 and rust-lang#46460 have been filed and are ref'd in a FIXME. This is hoped to resolve rust-lang#42929, rust-lang#44672, and rust-lang#45777.
bors
added a commit
that referenced
this issue
Jan 13, 2018
…e, r=estebank type error method suggestions use whitelisted identity-like conversions  Previously, on a type mismatch (and if this wasn't preëmpted by a higher-priority suggestion), we would look for argumentless methods returning the expected type, and list them in a `help` note. This had two major shortcomings: firstly, a lot of the suggestions didn't really make sense (if you used a &str where a String was expected, `.to_ascii_uppercase()` is probably not the solution you were hoping for). Secondly, we weren't generating suggestions from the most useful traits! We address the first problem with an internal `#[rustc_conversion_suggestion]` attribute meant to mark methods that keep the "same value" in the relevant sense, just converting the type. We address the second problem by making `FnCtxt.probe_for_return_type` pass the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe because grep reveals no other callers of `probe_for_return_type`. Also, structured suggestions are pretty and good for RLS and friends. Unfortunately, the trait probing is still not all one would hope for: at a minimum, we don't know how to rule out `into()` in cases where it wouldn't actually work, and we don't know how to rule in `.to_owned()` where it would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME. This is hoped to resolve #42929, #44672, and #45777.
crlf0710
added
the
T-compiler
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While working on improving method suggestions, it was discovered that the return value of
probe_for_return_type—at least, a slightly altered version thereof that passesProbeScope::AllTraitstoprobe_oprather thanProbeScope::TraitsInScope(as on master at issue-filing time)—could include methods that don't actually return the desired type. Most notably, this happened withcore::convert::Into::into.The root cause seems to be that when we try to resolve type variables, we might find that the return type of the trait method still needs to be resolved, and that unresolved type variable is considered to fulfill the required return type?? (I regret my difficulty to provide a better report than this.)
The text was updated successfully, but these errors were encountered: