Importing libraries leads to fully qualified types being shown unnecessarily

[Wilfred]

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:

• https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6ad4a050f56d960664fb2c44b5099796
• https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c82638d718acc86e87363cf8e7ab4ea0

[davidbarsky]

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))

[Noratrieb]

I think the issue here is that clap contains an item called String, so just using String 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]

I think the issue here is that clap contains an item called String

This appears to be the case. Minimized:

mod xx {
    struct String;   // doesn't need to be pub
}

fn wrong_type() -> Option<String> {
    return true;
}

or, two-crate version, more faithful to the original issue

// crate1
pub struct Foo;
pub struct String;

// crate2
use crate1::Foo;  // important to have *an* import from crate1

fn wrong_type() -> Option<String> {
    return true;
}

This is not a regression, the fully-qualified std::string::String is in the output all the way since 1.0.0. Although the core::option::Option did get shortened to just Option in #73996

I 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 the std::string::String that we meant. If we wanted to use any String not from prelude we would have to either fully qualify it, or add a use 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