[colbymchenry]

Summary

Builds on #1892 by @seonghobae, on the module walk of #3014 and the cross-crate paths of #3025: a Rust module loaded with #[path = "…"] is now the module that declares it.

• fast-mlsirm's #[path = "../../../tests/unit/scaling_tests.rs"] mod tests; in crates/core/src/scaling.rs: the test file's use super::* brings in scaling.rs's items, private ones included, so predict_rating_multi(1) links to scaling.rs's and not to another crate's namesake; its crate:: is core's.
• From the declaring side, a path through such a module reaches the file it names, even when several files load that file: each of dioxus's headless tests declares #[path = "./utils.rs"] mod utils; and calls utils::mock_event(…).
• tokio's atomic_u64_as_mutex.rs loads atomic_u64_static_const_new.rs (or …_once_cell.rs) with a #[path]: their use super::AtomicU64 is its AtomicU64.
• The path is read as the Rust Reference reads it: from the declaring file's directory, or inside an inline mod from that module's own. A module whose cfg alternatives each name a file (tokio's process::imp: unix/mod.rs or windows.rs), or whose path a cfg_attr sets, depends on the build and stays unknown; a path that leaves the project (escapesRoot) names no file.
• An example, test or bench that Cargo.toml places at a path of its own ([[example]] path = "examples/07-fullstack/handling_errors.rs") is its own crate's root, like [lib]/[[bin]] paths since fix(rust): use bindings follow Rust's scopes, and module paths walk the crate's modules #3014.

Root cause

rustSuperModule, rustFileModule, rustCrateRootModule and the visibility checks placed every file by its directory, and rustSubmodule returned nothing for a module with a #[path]. A #[path] file's directory says nothing about where it sits in the module tree: tests/unit/scaling_tests.rs is scaling.rs's mod tests.

Fix

• rustPathDeclsIn: a file's own #[path] declarations, read from its text (strings and comments blanked) after a byte check for path, with each target resolved per the Reference.
• Declaring side, rustSubmodule: a module declared once with a #[path] is the file it names.
• File side, rustPathClaim: a file the regular rules don't place is the module of the one #[path] declaration that loads it, if exactly one does. rustPlacedByName places crate roots, files with a fn main / #![no_main] of their own (trybuild cases, fuzz targets), and files a plain mod name; declares in the module owning their directory or in an inline module of one above it (dioxus's mod components { pub mod home; }). Only for a file left over does the resolver read the project's Rust files that write path = for their declarations, once per resolver. With a claim, rustSuperModule is the declaring module (the inline one around the attribute, if any), rustFileModule owns the file's directory (rustc reads every #[path] file as a mod.rs), rustCrateRootModule is the declaring file's crate, and rustModuleWithin, isRustItemVisibleFrom and isVisibleAcrossFiles see the file inside the declaring module.
• A path's 2015 crate-root fallback no longer reaches past a module the file declares with a #[path] to a namesake at the crate root.
• rustCrateGraph: [[example]], [[test]] and [[bench]] paths are target roots, kept inside the project through the same join.
• The import resolver's super is the same walk since fix(rust): use bindings follow Rust's scopes, and module paths walk the crate's modules #3014.

Validation

• Tests: fix(rust): resolve use super::* callees in #[path] modules #1892's rust-path-super-glob.test.ts (credited) and rust-path-attribute-modules.test.ts (private items through use super::*, crate::, an inline module's own directory, a helper two tests load, a folder named ..generated, an example at its own path, cfg alternatives and cfg_attr left unknown): on main all 8 fail; all pass. Every rust-* suite passes.

• A/B against main, native kernel, the 7 Rust repos, fast-mlsirm's Rust files and 2 controls:

  repo	added	retargeted	same item, now in scope	removed
  fast-mlsirm (Rust files, 115 #[path] modules)	2,796	71	87	0
  dioxus	27	0	0	0
  tokio	2	0	0	0
  ripgrep, axum, clap, serde, gleam	0	0	0	0
  express, flask	0	0	0	0

  fast-mlsirm: 1,839 calls, 427 references, 334 constructions and 196 imports added, mostly names use super::* brings in from the declaring module; retargets are the declaring module's own items (exposure_tests.rs's Lcg::next_f64 from cdm_tests.rs's private Lcg to exposure.rs's, the declaring module's gh_rule and helpers instead of bifactor_grm.rs's); the 87 reach the same item as before at confidence 0.9 instead of a 0.4 name guess. dioxus: the five headless tests' utils::… calls into their shared helper. tokio: the two use super::AtomicU64. Sampled and checked; every other repo is site-for-site identical.

• Cost (native kernel, medians of 3 interleaved runs):

  repo	CPU	wall	peak RSS
  fast-mlsirm (Rust files)	15.3 → 15.8 s	4.2 → 5.2 s	825 → 882 MB
  tokio	26.1 → 26.7 s	10.4 → 11.2 s	1,023 → 1,028 MB
  dioxus	34.8 → 35.6 s	10.3 → 11.2 s	1,125 → 1,120 MB
  gleam	24.1 → 23.8 s	6.6 → 6.7 s	1,027 → 1,023 MB

  The extra is reading the project’s #[path] declarations once per resolver: the main thread and each pool worker that reaches a file the regular rules don’t place (tokio’s atomic_u64_*.rs and process/unix/mod.rs, dioxus’s headless-test helper, fast-mlsirm’s test files). On this Windows machine that read is about 0.4 ms a file (file opens), 0.1–0.6 s per resolver; axum and ripgrep never do it, serde and gleam once on the main thread. With the resolver pool off (measured one revision earlier), fast-mlsirm is 9.8 → 10.4 s CPU, 4.7 → 5.0 s wall and 513 → 512 MB.

• Full suite (native kernel rebuilt from main, CODEGRAPH_KERNEL_EXPECT=1, daemon allowed, 4 workers) on this commit, on 2d98c1b: 815 files (809 passed, 6 skipped); 9,690 tests: 9,604 passed, 0 failed, 86 skipped.

Left out

• A file several #[path] declarations load (a shared test helper) has no single module, so its own super:: and crate:: stay unknown; calls into it from each declaring file resolve.
• Modules declared by a macro (serde_core's crate_root!) or by automod::dir! (clap's test suites) are not read as declarations, so those files still send the resolver to read the project's #[path] declarations once; they keep their directory's module.
• Each resolver pool worker reads the declarations for itself; sharing the main thread's would take the per-worker read off the repos that have #[path] modules.

🤖 Generated with Claude Code