std_instead_of_core: false positive with std::env since nightly-2024-03-08

[taiki-e]

Summary

Since nightly-2024-03-08, it seems that std_instead_of_core is not correctly handling cases where macros and modules have the same name.

Probably related to #12406, cc @MarcusGrass

Lint Name

std_instead_of_core

Reproducer

I tried this code:

#![allow(dead_code)]
#![warn(clippy::std_instead_of_core)]

use std::env;

fn f() -> Option<String> {
    env::var("FOO").ok()
}

I saw this happen:

warning: used import from `std` instead of `core`
 --> src/lib.rs:4:5
  |
4 | use std::env;
  |     ^^^ help: consider importing the item from `core`: `core`
  |

However, replacing std::env with core::env causes compile error:

#![allow(dead_code)]
#![warn(clippy::std_instead_of_core)]

use core::env;

fn f() -> Option<String> {
    env::var("FOO").ok()
}

error[E0433]: failed to resolve: use of undeclared crate or module `env`
 --> src/lib.rs:7:5
  |
7 |     env::var("FOO").ok()
  |     ^^^ use of undeclared crate or module `env`
  |
help: consider importing this module
  |
4 + use std::env;
  |

I expected to see this happen: no warning

Version

rustc 1.78.0-nightly (9c3ad802d 2024-03-07)
binary: rustc
commit-hash: 9c3ad802d9b9633d60d3a74668eb1be819212d34
commit-date: 2024-03-07
host: aarch64-apple-darwin
release: 1.78.0-nightly
LLVM version: 18.1.0

Additional Labels

@rustbot label +I-suggestion-causes-error

[MarcusGrass]

Yeah it's definitely caused by that, I didn't see it until now since I updated the expected output file, and didn't notice the erroneous fix from std::env to core::env it's pretty easily revertible without much hassle, but I'll have a look tomorrow to see if there's a reasonable fix, thanks for the report!

[MarcusGrass]

Yep, pretty stupid mistake, got a PR with the fix here #12447 preserves the bugfix that it was supposed to achieve.

[danwilliams]

@MarcusGrass @bors Just to note, I ran into this issue just now, after updating to 1.78.0 stable. I checked Git and it seems that although this fix was merged to master, it didn't make it into the 1.78.0 tag. I was going to open a ticket, but when searching I found this one...

[MarcusGrass]

@MarcusGrass @bors Just to note, I ran into this issue just now, after updating to 1.78.0 stable. I checked Git and it seems that although this fix was merged to master, it didn't make it into the 1.78.0 tag. I was going to open a ticket, but when searching I found this one...

Oh no that was a real miss, I'm fairly new to this project and didn't realize that the fix might miss the merge window, I'm sorry about that