rust_2024_prelude_collisions fails with glob of underscore import

[ehuss]

I tried this code:

#![warn(rust_2024_prelude_collisions)]

pub mod prelude {
    pub use crate::inner::FExt as _;
}

pub mod inner {
    pub trait FExt {
        fn into_future(self) -> StreamFuture
        where
            Self: Sized,
        {
            StreamFuture
        }
    }

    pub struct StreamFuture;

    pub struct F;
    impl FExt for F {}
}

use crate::prelude::*;

pub fn f() {
    let _ = crate::inner::F.into_future();
}

This generates a suggestion to modify the code like this:

@@ -23,5 +23,5 @@
 use crate::prelude::*;
 
 pub fn f() {
-    let _ = crate::inner::F.into_future();
+    let _ = FExt::into_future(crate::inner::F);
 }

However, this fails to compile with the following error:

error[E0433]: failed to resolve: use of undeclared type `FExt`
  --> src/lib.rs:26:13
   |
26 |     let _ = FExt::into_future(crate::inner::F);
   |             ^^^^ use of undeclared type `FExt`
   |
help: consider importing one of these traits
   |
23 + use crate::inner::FExt;
   |
23 + use f::FExt;
   |

warning: unused import: `crate::prelude::*`
  --> src/lib.rs:23:5
   |
23 | use crate::prelude::*;
   |     ^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

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

Because the _ import does not give the trait a name.

This comes up in real-life with importing use futures::prelude::*.

I'm not sure what the best solution to this would be. Perhaps it could detect a similar scenario, and fully qualify the path to the trait (like futures::StreamExt::into_future). Or just always fully qualify it?

Meta

rustc --version --verbose:

rustc 1.84.0-nightly (59cec72a5 2024-11-08)
binary: rustc
commit-hash: 59cec72a57af178767a7b8e7f624b06cc50f1087
commit-date: 2024-11-08
host: aarch64-apple-darwin
release: 1.84.0-nightly
LLVM version: 19.1.3

[compiler-errors]

I'm gonna leave a practicality note on this one and say that it'll be very difficult to generate a relevant use import suggestion here, since I don't think we keep that info around this late.

[traviscross]

In talking with @ehuss on the edition call, he had proposed, rather than trying to import this with use, to convert the call into a fully-qualified form with the path.

We asked @compiler-errors about this, and he indicated that this should be possible, but that it may be difficult to determine when using the full path is necessary.

It'd probably be good to do something here, if we can, given that the use futures::prelude::* seems to have been one of the main motivating cases for this lint.

cc @Noratrieb