`module_path!` expansion incorrect for modules without canonical path

[cyqsimon]

When module_path! is used inside a module without a canonical path, it expands to an incorrect module path.

fn main() {
    print_inner_path(); // prints `<CRATE_NAME>::fn_inner`
    // according to `module_path` this should work; obviously it shouldn't and doesn't
    //dbg!(crate::fn_inner::PATH);
}
fn print_inner_path() {
    pub mod fn_inner {
        pub const PATH: &str = module_path!();
    }
    println!("module path: {}", fn_inner::PATH);
}

Playground

I consider this expansion incorrect because it doesn't indicate that fn_inner is in fact a nested module in a function and is not externally reachable. There's also the possibility that there exists a reachable module at the same level with the same name, from which module_path! would expand to the same thing despite being two distinct modules. See comment.

I'm not sure what the appropriate output/action would be in this situation. A placeholder text or empty string maybe? Although this sounds very wrong. Or maybe compile error. Regardless, at minimum I think the documentation for module_path! should be updated to address this limitation/bug.

Meta

rustc --version --verbose:

rustc 1.92.0-nightly (52618eb33 2025-09-14)
binary: rustc
commit-hash: 52618eb338609df44978b0ca4451ab7941fd1c7a
commit-date: 2025-09-14
host: x86_64-unknown-linux-gnu
release: 1.92.0-nightly
LLVM version: 21.1.1

[hanna-kruppe]

The return value is correct in that it describes the module hierarchy from the immediately enclosing module up to the crate root. Returning an empty string or failing compilation isn’t useful for intended usage of the macro (e.g., logging). I also don’t see any implication in the documentation that the returned string is the canonical path or otherwise a valid Rust expression. Indeed the canonical path is defined relative to the crate root while module_path includes the crate name as first component. It may be helpful to spell out what module_path isn’t in the documentation but I don’t think there’s anything wrong about the current behavior.

[cyqsimon]

It may be helpful to spell out what module_path isn’t in the documentation

Yeah I agree. Perhaps something like type_name.

---

There may be some misunderstanding about what I have a problem with. The fact that module_path! uses the crate name as the first component is okay, even desirable for debugging purposes. I see no problem with this.

What I do have a problem with is how the current output gives no indication that the module is in fact nested within a function and is unreachable. Consider this example:

fn main() {
    print();
}
mod foo {
    pub const PATH: &str = concat!("outer module: ", module_path!());
}
fn print() {
    pub mod foo {
        pub const PATH: &str = concat!("inner module: ", module_path!());
    }
    println!("{}", crate::foo::PATH);
    println!("{}", foo::PATH);
}

Playground

It prints playground::foo twice, even though they are distinct modules. Hopefully you can see why I am using such a strong word as "incorrect".

Perhaps better would be for the latter case to expand to something like playground::<FN_INTERNAL_print>::foo. Maybe there is something better but this is the best that comes to my mind at the moment.

There's also stability concerns with changing this. But given that the current expansion already doesn't "work" if someone tries to use it programmatically (which is conceivable), this may not be that great of a concern.