nice_name should be used in diagnostics of extern crate icky_name as nice_name

[anforowicz]

Code

extern crate unwieldy_crate_name as nice_crate_name;

fn use_foo_from_another_crate_without_importing_it_first() {
    // This will expectedly error out saying:
    // error[E0412]: cannot find type `Foo` in this scope
    //
    // The ergonomics issue is that the fix suggestion may refer to the
    // `unwieldy_crate_name` instead of `nice_crate_name`:
    //
    // help: consider importing this struct
    //   |
    // 1 + use unwieldy_crate_name::Foo;
    //   |

    let _: Foo<_> = todo!();
}

Current output

error[E0412]: cannot find type `Foo` in this scope
  --> ./repro.rs:15:12
   |
15 |     let _: Foo<_> = todo!();
   |            ^^^ not found in this scope
   |
help: consider importing this struct
   |
1  + use unwieldy_crate_name::Foo;
   |

Desired output

error[E0412]: cannot find type `Foo` in this scope
  --> ./repro.rs:15:12
   |
15 |     let _: Foo<_> = todo!();
   |            ^^^ not found in this scope
   |
help: consider importing this struct
   |
1  + use nice_crate_name::Foo;

Rationale and extra context

Some build environments (e.g. Chromium (*), Bazel) may generate crate names based on names of build targets. While this results in globally-unique (**) crate names, it results in long and quite unwieldy crate names. Both Chromium and Blaze provide a macro to help working with such crate names:

chromium::import! {
    "//third_party/blink/renderer/platform/image-decoders/rust_bindings:scoped_refptr";
}

The macro usage above expands to something like:

extern crate third_uparty_sblink_srenderer_splatform_simage_ddecoders_srust_ubindings_cscoped_urefptr as scoped_refptr; 

Unfortunately, it seems that some rustc diagnostics keep referring to the long and unwieldy name.

(*) see chromium_prelude/import_attribute.rs and chromium/build/rust/rust_static_library.gni
(**) globally-unique crate names = within a given build tree

Other cases

No response

Rust Version

$ rustc --version --verbose
rustc 1.78.0-nightly (ee9c7c940 2024-02-14)
binary: rustc
commit-hash: ee9c7c940c07d8b67c9a6b2ec930db70dcd23a46
commit-date: 2024-02-14
host: x86_64-unknown-linux-gnu
release: 1.78.0-nightly
LLVM version: 18.1.0

Anything else?

More detailed repro can be found below:

$ cat unwieldy_crate_name.rs
pub struct Foo<T>(pub core::ptr::NonNull<T>);

$ cat repro.rs
extern crate unwieldy_crate_name as nice_crate_name;

fn use_foo_from_another_crate_without_importing_it_first() {
    // This will expectedly error out saying:
    // error[E0412]: cannot find type `Foo` in this scope
    //
    // The ergonomics issue is that the fix suggestion may refer to the
    // `unwieldy_crate_name` instead of `nice_crate_name`:
    //
    // help: consider importing this struct
    //   |
    // 1 + use unwieldy_crate_name::Foo;
    //   |

    let _: Foo<_> = todo!();
}

$ rustc --crate-type rlib --edition=2021 ./unwieldy_crate_name.rs

$ rustc --crate-type rlib --edition=2021 ./repro.rs --extern unwieldy_crate_name=./libunwieldy_crate_name.rlib
error[E0412]: cannot find type `Foo` in this scope
  --> ./repro.rs:15:12
   |
15 |     let _: Foo<_> = todo!();
   |            ^^^ not found in this scope
   |
help: consider importing this struct
   |
1  + use unwieldy_crate_name::Foo;
   |

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0412`.

[anforowicz]

Is this something worth fixing? Is the original crate name worth preferring over the aliased name in some scenarios?

[anforowicz]

BTW: I also want to note/highlight that I am not able to repro the problem without using --edition=2021. For example (same .rs files):

$ rustc --crate-type rlib ./unwieldy_crate_name.rs

$ rustc --crate-type rlib ./repro.rs --extern unwieldy_crate_name=./libunwieldy_crate_name.rlib
error[E0412]: cannot find type `Foo` in this scope
  --> ./repro.rs:15:12
   |
15 |     let _: Foo<_> = todo!();
   |            ^^^ not found in this scope
   |
help: consider importing this struct
   |
1  + use nice_crate_name::Foo;
   |

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0412`.

[anforowicz]

/cc @danakj