rust-lang / rust-lang/rust

`module_path!` expansion incorrect for modules without canonical path

Open
#146,624 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-docs A-macros T-compiler
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the provided Playground reproduction and the module_path! documentation and canonical-paths reference. Investigate how the macro expands for a module declared inside a function and compare that with the documented behavior. Done requires a decided behavior for non-canonical modules and either an implementation with coverage or documentation that clearly explains the limitation.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.