Open
Description
Code
use clap::Parser;
fn wrong_type() -> Option<String> {
return true;
}
Current output
error[E0308]: mismatched types
--> src/lib.rs:4:12
|
3 | fn wrong_type() -> Option<String> {
| -------------- expected `Option<std::string::String>` because of return type
4 | return true;
| ^^^^ expected `Option<String>`, found `bool`
|
= note: expected enum `Option<std::string::String>`
found type `bool`
Desired output
error[E0308]: mismatched types
--> src/lib.rs:4:12
|
3 | fn wrong_type() -> Option<String> {
| -------------- expected `Option<String>` because of return type
4 | return true;
| ^^^^ expected `Option<String>`, found `bool`
|
= note: expected enum `Option<String>`
found type `bool`
Rationale and extra context
Adding imports, even though they don't introduce another String
type in the current file, is making rustc print fully qualified type names.
Clap doesn't define any types called String
, although it does have a variant named String
elsewhere in the library: https://docs.rs/clap/latest/clap/error/enum.ContextValue.html#variant.String
Other cases
There's a similar issue with serde and option:
use serde::Deserialize;
fn wrong_type() -> Option<String> {
return true;
}
rustc output:
error[E0308]: mismatched types
--> src/lib.rs:4:12
|
3 | fn wrong_type() -> Option<String> {
| -------------- expected `std::option::Option<std::string::String>` because of return type
4 | return true;
| ^^^^ expected `Option<String>`, found `bool`
|
= note: expected enum `std::option::Option<std::string::String>`
found type `bool`
Anything else?
Playground links:
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
davidbarsky commentedon Jul 21, 2023
Using the same program that @Wilfred wrote,
env RUSTFLAGS="-Ztrim-diagnostic-paths=true" cargo +nightly check
results in fully-qualified types showing up in diagnostics as well.(I'm using
rustc 1.73.0-nightly (399b06823 2023-07-20)
)[-]Importing libraries leads to fully qualified types being shown unnecessairly[/-][+]Importing libraries leads to fully qualified types being shown unnecessarily[/+]Noratrieb commentedon Aug 8, 2023
I think the issue here is that
clap
contains an item calledString
, so just usingString
is not fully unambiguous anymore. The fact that it's an enum variant which cannot be a type is not considered by the compiler (and I'm not sure whether it should be, erring on the side of "no").moxian commentedon Mar 20, 2025
This appears to be the case. Minimized:
or, two-crate version, more faithful to the original issue
This is not a regression, the fully-qualified
std::string::String
is in the output all the way since 1.0.0. Although thecore::option::Option
did get shortened to justOption
in #73996I believe there is no need to fully qualify
String
here because it is unambiguous in this case. After all, the diagnostics machinery was able to correctly identify thestd::string::String
that we meant. If we wanted to use anyString
not from prelude we would have to either fully qualify it, or add ause
for it.Now, whether or not the extra qualification is useful (and thus whether rustc is working as intended here), I can't say.
@rustbot label: -E-needs-bisection +D-verbose