`imports_granularity=One` removes macro imports that share names with modules

[lars-schumann]

#![no_implicit_prelude]
extern crate alloc;

use alloc::boxed;
use alloc::vec;
use alloc::vec::Vec;

fn main() {
    let _: Vec<i32> = vec![];
}

turns into

#![no_implicit_prelude]
extern crate alloc;

use alloc::{
    boxed,
    vec::{self, Vec},
};

fn main() {
    let _: Vec<i32> = vec![];
}

after

$ rustfmt --unstable-features --config imports_granularity=One ./src/main.rs

This is no longer valid rust, as the vec! macro isnt in scope anymore.

tested on latest nightly:

$ rustfmt -V
rustfmt 1.8.0-nightly (d5419f1e97 2025-10-30)
$ rustc -V
rustc 1.93.0-nightly (d5419f1e9 2025-10-30)

[Manishearth]

Oof, this would require rustfmt to know about where macros are. This might make imports_granularity=One completely infeasible?

Or rustc should decide that alloc::vec::self imports the macro too.

[Manishearth]

I guess this can still be handled by merging this into use alloc::{vec, vec::...}.

[jieyouxu]

Oof, this would require rustfmt to know about where macros are. This might make imports_granularity=One completely infeasible?

Or rustc should decide that alloc::vec::self imports the macro too.

I don't think the latter is a viable option, or at least it would have to be done over an language edition boundary.

The former is indeed a problem -- it would require that whichever stylistic transformation rustfmt performs need to respect that there are three major namespaces (types, macros, values), and collapsing to *::self is not a generally-valid transformation where there is a same name in different namepsaces (in this case, the name is in both macro namespace and type namespace).

For instance, this is another variant where the *::self-collapse transformation would change the program from compile-pass -> compile-fail (there is a foo in both type namespace and value namespace):

#![allow(dead_code, unused_imports)]
mod outer {
    pub struct Meow;

    pub mod foo {
        // module name is in type namespace
        pub struct Bar;
    }

    pub fn foo() {
        // function name is in value namespace
        println!("hi");
    }
}

fn main() {
    use outer::Meow;
    use outer::foo;
    use outer::foo::Bar;

    let _ = Meow;
    foo();
    let _ = Bar;
}

Under imports_granularity=One, this will compile-fail:

#![allow(dead_code, unused_imports)]
mod outer {
    pub struct Meow;

    pub mod foo {
        // module name is in type namespace
        pub struct Bar;
    }

    pub fn foo() {
        // function name is in value namespace
        println!("hi");
    }
}

fn main() {
    use outer::{
        Meow,
        foo::{self, Bar}, // `foo` in the value namespace is no longer imported
                          // because of the `::self` transformation.
    };

    let _ = Meow;
    foo();
    let _ = Bar;
}

[jieyouxu]

Since rustfmt surely does not have type-agnostic name resolution information, I think for imports_granularity=One it would necessarily have to pick a conservative transformation and avoid using ::self transformation at all times (modulo a few known-safe carve outs, but can't come up with examples on top of my head right now). Or I suppose maybe using some heuristics for this case is sufficient? Not quite sure.

[jieyouxu]

I guess the main worry here is indeed about the general case, since collapsing imports need to fully respect the distinction between the three major namespaces.