"Failed to find module $foo in $path None" when an integration test has a module of the same name

[shepmaster]

To Reproduce

.
├── Cargo.toml
├── src
│   └── lib.rs
└── tests
    ├── level1
    │   └── level2.rs
    └── level1.rs

• src/lib.rs is empty.

• tests/level1.rs

  mod level1 {
      mod level2;
  }

• tests/level1/level2.rs

  #[test]
  fn dummy() {}

cargo test

running 1 test
test level1::level2::dummy ... ok

cargo fmt
Error writing files: io error: Failed to find module level2 in ".../repro/tests/level1/level1" None

Expected behavior

The file would be found and formatted.

Meta

• rustfmt version: rustfmt 1.4.17-stable (8a93416c 2020-07-20); rustfmt 1.4.18-stable (8157a3f0 2020-07-15)
• From where did you install rustfmt?: rustup
• How do you run rustfmt: cargo-fmt

[calebcartwright]

This has been fixed in source (on the master/v2.0 branch) but hasn't been released yet.

v1.4.20 currently on nightly has the first part of this that includes improved error messages, and I'll look into backporting the remainder to a future 1.x release.

Going to go ahead and close though as there's no additional changes to be made to rustfmt

[shepmaster]

This was fixed(?) in rustfmt 1.4.37-stable (2a3635d5 2021-05-04) and regressed in rustfmt 1.4.37-stable (a178d032 2021-07-26). It seems surprising that they have the same version number for different hashes...

% cargo +1.53 fmt
% cargo +stable fmt
Error writing files: failed to resolve mod `level2`: /private/tmp/repro/tests/level1/level1 does not exist

[shepmaster]

I'll look into backporting the remainder to a future 1.x release.

Is there an issue I can follow to track any potential progress, seeing as how this one is closed?

[shepmaster]

I didn't look to see how long Cargo has supported this, but you can create subdirectories in tests and then have regular modules there. That solves my original problem and rustfmt doesn't complain.

[calebcartwright]

Apologies. This slipped through my notifications inbox without a response.

There is a closed issue somewhere that (hopefully) has the corresponding backporting status label on it, but don't have it handy. Will cross post here for awareness once i find it and once backported will add a note to both so that subscribed folks will know.

This is largely a matter of going back and grabbing the corresponding commits that fixed it for 2.x, and likely reshaping them given how much the module resolution portion of the code had diverged between the two branches. Not something I'll get to in the immediate future but it's pretty high up on my list.

This was fixed(?) in

Not to my knowledge. I suspect what you're seeing was a bug that existed for a while where rustfmt incorrectly failed to even attempt to load such modules (which would have resulted in the error message not being presented).

It seems surprising that they have the same version number for different hashes.

rustfmt changed from a submodule to a subtree in r-l/rust not too long ago, so it's not uncommon for compiler contributors to also update rustfmt source as they make their changes, particularly to the AST and/or parser. The semver portion of the version is something we update when we sync more significant changes from here to there.

Long term I'm not sure how much sense it makes to continue having rustfmt versioned independently, but that's a separate topic altogether