Regression against 1.0.3: "error[E0583]: file not found for module"

[rotty]

With a 2015-edition crate, "cargo fmt" fails on both current beta and nightly, whereas stable works:

% cargo fmt --version && cargo fmt -- --check
rustfmt 1.0.3-stable (d6829d6 2019-02-14)
% cargo +nightly fmt --version && cargo +nightly fmt -- --check
rustfmt 1.2.2-nightly (5274b49 2019-04-24)
error[E0583]: file not found for module `common`
  --> /home/rotty/src/crates/zmq/tests/connection.rs:13:5
...
% cargo +beta fmt --version && cargo +beta fmt -- --check
error[E0583]: file not found for module `common`
...

Note that for beta, the --version flag seems to be broken as well; it yields no output, although rustfmt --version works:

% rustup run beta rustfmt --version
rustfmt 1.2.0-beta (09940a7 2019-03-27)

Anyway, to reproduce, you can run the following:

% git clone -b rustfmt-issue/file-not-found https://github.com/rotty/rust-zmq.git
% cd rust-zmq
% cargo +nightly fmt -- --check
error[E0583]: file not found for module `common`
...
% cargo fmt -- --check

[rotty]

Note that changing to the 2018 edition for the rust-zmq crate did not help, the same error message is produced by cargo +beta fmt.

[topecongiro]

A minimal working example

Create a rust file with a submodule declaration and a directory whose name is the same as the rust filename.

src
├── common
│   └── mod.rs
├── connection/
└── connection.rs

src/connection.rs

mod common;

[Thomasdezeeuw]

I think I found a similar, likely related, error but it only fails on tests. Running cargo fmt on the following files result in the following error

error[E0583]: file not found for module `thing`
 --> /rustfmt_test/tests/functional.rs:2:9
  |
2 |     mod thing;
  |         ^^^^^
  |
  = help: name the file either thing.rs or thing/mod.rs inside the directory "/rustfmt_test/tests/functional/functional"

The files.

// /tests/functional.rs
mod functional {
    mod thing;
}

// /tests/functional/thing.rs
#[test]
fn some_test() { assert!(true); }

As the error suggests it uses the functional directory twice. Calling cargo test works just fine.

[Thomasdezeeuw]

We're hitting this error in Mio (tokio-rs/mio#1030), is there any work around for this?

[calebcartwright]

On the original example in the OP, does adding an explicit path attribute help?

I.e. in tests/connection.rs something like:

#[macro_use]
#[path = "common/mod.rs"]
mod common;

[Thomasdezeeuw]

@calebcartwright The following doesn't work (this is actual code as in tokio-rs/mio#1030). I get Error writing files: io error: Failed to find module poll in "functional" None as error.

#[path = "functional"]
mod functional {
    mod poll;
}

A found a possible workaround in the following.

#[path = "functional/poll.rs"]
mod poll;

[calebcartwright]

Thanks @Thomasdezeeuw. I tested adding the path with the sample repo linked in the original note, but didn't get a chance to look at the Mio codebase.

Are you saying that the snippet you posted using path provides a work around for you in Mio?

#[path = "functional/poll.rs"]
mod poll;

[Thomasdezeeuw]

I ended up needing to write a way to complicate macro as can be seen here: https://github.com/tokio-rs/mio/blob/8abd613656c7438fc8b783f1630a9f61532b5444/tests/functional.rs. But yes that should work.

I'm not familiar with the rustfmt code base, but to me it seems that rustc and rustfmt handle module paths differently when the module is not in its own directory, i.e. functional.rs instead of functional/mod.rs. I think this because we've hit another (similar bug) that doesn't use path, where the mod util (in the previously linked file) is also not found by rustfmt, but it's fine for rustc. See https://dev.azure.com/tokio-rs/Tokio/_build/results?buildId=1511&view=logs&jobId=f14073de-e1a4-5ba6-5dc1-4c667fb92951 for the error.

[kentfredric]

I wrote a crappy bash script that will simulate one example of this failure, just cd /tmp/foodir or something before you run it.

set -v -o pipefail

# Some diagnostics
cargo --version
cargo fmt --version
# Create a repo
cargo new --lib --vcs git --edition 2018 demo
cd demo
# Minimal working structure
echo "mod foo;" > src/lib.rs
touch src/foo.rs
cargo build
cargo fmt

# Cleanup target dir juuust in case
rm -r target

# Break the build
mkdir src/lib

# Cargo is still fine
cargo build

# But rustfmt ... yeah nah
cargo fmt

So still failing with

cargo 1.39.0-nightly (22f7dd049 2019-08-27)
rustfmt 1.4.6-nightly (f800ce4 2019-08-28)

The crappy part really is how an empty directory can even mess this up, which is annoying, because you don't see empty directories in git status >_>

[mahkoh]

Possibly fixed by #4194