Skip to content

Importing libraries leads to fully qualified types being shown unnecessarily #113933

Open
@Wilfred

Description

@Wilfred
Contributor

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:

Activity

added
A-diagnosticsArea: Messages for errors, warnings, and lints
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
on Jul 21, 2023
added
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Jul 21, 2023
davidbarsky

davidbarsky commented on Jul 21, 2023

@davidbarsky
Contributor

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

changed the title [-]Importing libraries leads to fully qualified types being shown unnecessairly[/-] [+]Importing libraries leads to fully qualified types being shown unnecessarily[/+] on Jul 21, 2023
added
E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc
on Jul 22, 2023
Noratrieb

Noratrieb commented on Aug 8, 2023

@Noratrieb
Member

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

removed
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Aug 8, 2023
moxian

moxian commented on Mar 20, 2025

@moxian
Contributor

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

added
D-verboseDiagnostics: Too much output caused by a single piece of incorrect code.
and removed
E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc
on Mar 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsD-verboseDiagnostics: Too much output caused by a single piece of incorrect code.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @Wilfred@davidbarsky@moxian@saethlin@rustbot

        Issue actions

          Importing libraries leads to fully qualified types being shown unnecessarily · Issue #113933 · rust-lang/rust