Skip to content
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

E0308 error message does not suggest to_string() for converting from &str to String #44672

Closed
feadoor opened this issue Sep 18, 2017 · 3 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. WG-diagnostics Working group: Diagnostics

Comments

@feadoor
Copy link
Contributor

feadoor commented Sep 18, 2017

This snippet:

fn foo(s: String) {}

fn main() {
    let s = "this is a &str";
    foo(s);
}

results in the following compiler error:

error[E0308]: mismatched types
 --> src/main.rs:6:9
  |
6 |     foo(s);
  |         ^ expected struct `std::string::String`, found &str
  |
  = note: expected type `std::string::String`
             found type `&str`
  = help: here are some functions which might fulfill your needs:
          - .escape_debug()
          - .escape_default()
          - .escape_unicode()
          - .to_lowercase()
          - .to_uppercase()

error: aborting due to previous error

error: Could not compile `playground`.

To learn more, run the command again with --verbose.

It would be nice if this error message suggested the function which is actually most likely to be helpful here, which is to_string().

@feadoor feadoor changed the title E308 error message does not suggest to_string() for converting from &str to String E0308 error message does not suggest to_string() for converting from &str to String Sep 18, 2017
@arielb1
Copy link
Contributor

arielb1 commented Sep 18, 2017

I think it just never looks up traits in scope, because the traits in scope list is empty. cc @jseyfried again for re-running resolution during method lookup.

@Mark-Simulacrum Mark-Simulacrum added A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Sep 18, 2017
@zackmdavis
Copy link
Member

(related: #45777, #42929)

@estebank estebank added the WG-diagnostics Working group: Diagnostics label Dec 8, 2017
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

![method_jamboree_summit](https://user-images.githubusercontent.com/1076988/33523646-e5c43184-d7c0-11e7-98e5-1bff426ade86.png)

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.
@estebank
Copy link
Contributor

Current output:

error[E0308]: mismatched types
 --> src/main.rs:5:9
  |
5 |     foo(s);
  |         ^
  |         |
  |         expected struct `std::string::String`, found &str
  |         help: try using a conversion method: `s.to_string()`
  |
  = note: expected type `std::string::String`
             found type `&str`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-enhancement Category: An issue proposing an enhancement or a PR with one. WG-diagnostics Working group: Diagnostics
Projects
None yet
Development

No branches or pull requests

5 participants