Rustfmt fails to resolve mod

[Skgland]

Reproduction

git clone https://github.com/Skgland/scryer-prolog.git
pushd scryer-prolog
git checkout --track origin/rustfmt/issue1
cargo check # succeeds
cargo fmt --all # Error writing files: failed to resolve mod `macros`: /home/bennet/Git/tmp/scryer-prolog/src does not exist

#5167 has a similar error message but this one should not be ambiguous.

[ytmimi]

Thanks for the report!

At a quick glance over the repo (https://github.com/Skgland/scryer-prolog.git) it does seem like this should be different than 5167. I'll try to dig into this over the next few days to see if I can better understand what's going on.

[ytmimi]

After diving into the rustfmt module resolution code and revisiting your repo I've identified that the issue is that you define both a src/lib directory (that doesn't contain any rust code) and a src/lib.rs file.

module resolution is trying to look for modules in the src/lib directory and because we can't find:
src/lib/macros.rs or src/lib/macros/mod.rs We run into a rustc_expand::module::ModError::FileNotFound error when we call ParseSess::default_submod_path.

rustfmt/src/modules.rs

Lines 372 to 374 in 8b0b213

	match self
	.parse_sess
	.default_submod_path(mod_name, relative, &self.directory.path)

Just as a note, our implementation of ParseSess::default_submod_path just forwards values to rustc_expand::module::default_submod_path, so if this is a recent issue then maybe things changed in the compiler (but I can't be sure of that).

That being said, I think I have a fix for this.

[Skgland]

No, this does not appear to be a recent issue, I tried most rust stables back to 1.46.0 (2020-08-27) and could reproduce this with all tried versions and src/lib.rs was only introduced on 2021-02-28 when splitting of the lib in mthom/scryer-prolog@2f428b7.

[ytmimi]

Thanks for the additional info. I'm pretty confident that it was the introduction of the src/lib.rs file that caused this module resolution issue. I should have a PR to fix this soon!