Skip to content

Shorter type-names on type errors #50310

Closed

Description

Type errors (E0308) are a common occurrence in rustc. Whenever I confuse myself about the type of something, I tend to assign it to some x: i32 and let the compiler blame me with a hint about what type x actually is. The note-section attached to the error message contains the fully qualified type name, which is technically as correct as one can get. However, this also produces a lot of clutter, because the type-name that I'm actually interested in is much more concise if types in scope of the offending statement are taken into account. For example:

use std::collections::HashMap;

fn foobar(x: &i32) {
    
}

fn main() {
    let mut foo = HashMap::new();
    foo.insert("foo", Ok(Some("bar")));
    foo.insert("oof", Err("Oh noes!"));
    
    foobar(&foo);
    
    println!("{:#?}", foo);
}

The note says

found type std::collections::HashMap<&str, std::result::Result<std::option::Option<&str>, &str>>

Again, while this is as precise as it can get, most of this is just clutter, especially with deeply nested types: I know that HashMap is from std::collections, I also know that Option refers to std::option::Option. If I had some other type shadowing those names, I'd be aware of it. Reading the note, I have to demangle the type-name to

found type HashMap<&str, Result<Option<&str>, &str>>

which is what the type-name would be if I wanted to write it down, considering all the uses.

Could we at least have an option (or an extra note) for E0308 where the type-names get uncluttered by considering the types that are in scope for the offending statement? This would reduce the intellectual burden and may enable one to just copy&paste the type-name from the note.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsC-enhancementCategory: An issue proposing an enhancement or a PR with one.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

    Issue actions