single_component_path_imports with macros and $crate::

[ijackson]

Summary

In exported macros, it is often necessary to write things like $crate::some_other_crate::its_thing, and arrange to reexport some_other_crate, to avoid imposing strange import requirements on other crates that use the macro.

If one writes a macro that is currently not exported, but one might want to export in the future, it is a good idea to do this, because nothing will spot a failure to do it later when the macro becomes exported.

But, then, one gets a single_component_path_imports false positive due to the single element path import of some_other_crate, which is necessary for the $crate to work, but which also ought to be private.

I found #7168 which is a complaint about the same kind of situation, but in that case arguably the code ought to be changed. I think in my case the code is fine as it is.

Lint Name

single_component_path_imports

Reproducer

I tried this code:

#![warn(clippy::all)]

// Without this line:
//   $crate::rand::random()
//           ^^^^ unresolved import
//
// With this line:
//   warning: this import is redundant
//   help: remove it entirely
use rand;

mod m {
    // At some future point, we plan to make this an exported macro,
    // so let's do the $crate::... thing.
    macro_rules! use_rand { {} => {
        $crate::rand::random()
    } }

    pub fn mk() -> u32 {
        use_rand!()
    }
}

fn main() {
    println!("{}", m::mk());
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=387d054d9673c5e30737f65c4a47a23a

I saw this happen:

warning: this import is redundant
  --> src/main.rs:10:1
   |
10 | use rand;
   | ^^^^^^^^^ help: remove it entirely
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#single_component_path_imports
note: the lint level is defined here
  --> src/main.rs:1:9
   |
1  | #![warn(clippy::all)]
   |         ^^^^^^^^^^^
   = note: `#[warn(clippy::single_component_path_imports)]` implied by `#[warn(clippy::all)]`

I expected to see this happen:

No complaint.

Version

1.64.0 stable in the playground, 2018 edition.

The bug does not seem to appear in the playground with 2021 edition.

Additional Labels

@rustbot label +suggestion-causes-error

[rustbot]

Error: Label suggestion-causes-error can only be set by Rust team members

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.