Skip to content

Rustfmt can't find module if a directory and module is named the same #3794

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
Closed
Marwes opened this issue Sep 13, 2019 · 9 comments
Closed

Rustfmt can't find module if a directory and module is named the same #3794

Marwes opened this issue Sep 13, 2019 · 9 comments
Labels
fixed

Comments

@Marwes
Copy link
Contributor

Marwes commented Sep 13, 2019 •
edited
Loading

Reproduction, clone https://github.com/Marwes/rustfmt-bug and run cargo fmt.

error[E0583]: file not found for module `support`
 --> /home/markus/Code/rustfmt-bug/tests/test.rs:1:5
  |
1 | mod support;
  |     ^^^^^^^
  |
  = help: name the file either test/support.rs or test/support/mod.rs inside the directory "/home/markus/Code/rustfmt-bug/tests"

Since both tests/test.rs and tests/test/ exists, rustfmt is unable to find tests/support/mod.rs as mod support; as it appears that rustfmt thinks that test.rs is part of the tests/test/ module tree. This is different from how rustc/cargo sees it which compile the code happily.

I guess rustc/cargo has different module resolution for tests/ than src/ since rustfmt's behaviour would be correct in src/.

Workaround is to use #[path = "module.rs"] on the offending module.
@rchaser53
Copy link
Contributor

How about this?
cargo fmt -- tests/*/*.rs tests/*.rs

@Marwes
Copy link
Contributor Author

Marwes commented Sep 14, 2019 

$ cargo fmt -- tests/*/*.rs tests/*.rs
error[E0583]: file not found for module `support`
 --> \\?\C:\Users\Markus\Dropbox\Programming\rustfmt-bug\tests\test.rs:1:5
  |
1 | mod support;
  |     ^^^^^^^
  |
  = help: name the file either test\support.rs or test\support\mod.rs inside the directory "\\?\C:\Users\Markus\Dropbox\Programming\rustfmt-bug\tests"

error[E0583]: file not found for module `support`
 --> \\?\C:\Users\Markus\Dropbox\Programming\rustfmt-bug\tests\test.rs:1:5
  |
1 | mod support;
  |     ^^^^^^^
  |
  = help: name the file either test\support.rs or test\support\mod.rs inside the directory "\\?\C:\Users\Markus\Dropbox\Programming\rustfmt-bug\tests"

@rchaser53
Copy link
Contributor

Do you use Windows?
cargo fmt -- tests/*/*.rs tests/*.rs works in macOS(10.14.6).
It seems to be a problem that depends on Windows.

@Marwes
Copy link
Contributor Author

Marwes commented Sep 14, 2019

cargo fmt -- tests/*/*.rs tests/*.rs was run on windows but plain cargo fmt breaks on linux as well.

@rchaser53
Copy link
Contributor

I succeeded to reproduce the bug on ubuntu 18.04. Thank you.

@rchaser53
Copy link
Contributor

The rustfmt was in my environment a bit old.
This bug is also happended on the latest rustfmt on macOS.

@topecongiro
Copy link
Contributor

As a workaround, the following command may work if you are using nightly (you also need fd):

rustfmt --unstable-features --skip-children `fd -e rs`

jeikabu added a commit to jeikabu/runng that referenced this issue Oct 19, 2019
@jeikabu
Temporarily disable rustfmt
d94bb19 
- Issue with tests and modules causes rustfmt to fail (rust-lang/rustfmt#3794)
- Will re-organize tests in 0.3 branch to fix.  Don't want to do it here to avoid merge conflicts.
@pnkfelix pnkfelix mentioned this issue May 15, 2020
Open
@pnkfelix
Copy link
Member

(It would be good if this issue's title included the detail that its specifically about resolution in cargo tests/ directory. At least, that detail was quite relevant to me when I was trying to figure out what was wrong when I encountered it.)

pnkfelix added a commit to pnkfelix/cargo-bisect-rustc that referenced this issue May 15, 2020
@pnkfelix
Infrastructure for testing the command line tool.
1192338 
Note: generates tests into fresh temp dir, which is deleted after testing is
done (regardless of success or failure). You can change the
`which_temp::WhichTempDir` type to revise this behavior.

This infrastructure includes two tests: `tests/cli.rs` and `tests/ice.rs`. Each
uses very different strategies for testing cargo-bisect-rustc.

  1. `tests/cli.rs` uses a so-called meta-build strategy: the test inspects the
     `rustc` version, then generates build files that will inject (or remove,
     e.g. when testing `--regress=success`) `#[rustc_error]` from the source
     code based on the `rustc` version. This way, we get the effect of an error
     that will come or go based solely on the `rustc` version, without any
     dependence on the actual behavior of `rustc` itself (beyond its version
     string format remaining parsable).

     * This strategy should remain usable for the foreseeable future, without
       any need for intervention from `cargo-bisect-rustc` developers.

  2. `tests/ice.rs` uses a totally different strategy: It embeds an ICE that we
     know originated at a certain version of the compiler. The ICE is embedded
     in the file `src/ice/included_main.rs`. The injection point associated with
     the ICE is encoded in the constant `INJECTION_COMMIT`.

     * Over time, since we only keep a certain number of builds associated with
       PR merge commits available to download, the embedded ICE, the
       `INJECTION_COMMIT` definition, and the search bounds defined in
       `INJECTION_LOWER_BOUND` and `INJECTION_UPPER_BOUND` will all have to be
       updated as soon as the commit for `INJECTION_COMMIT` is no longer
       available for download.

     * Thus, this testing strategy requires regular maintenance from the
       `cargo-bisect-rustc` developers. (However, it is more flexible than the
       meta-build strategy, in that you can embed arbitrary failures from the
       recent past using this approach. The meta-build approach can only embed
       things that can be expressed via features like `#[rustc_error]`, which
       cannot currently express ICE's.

----

Includes suggestions from code review

Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>

----

Includes some coments explaining the `WhichTempDir` type. (That type maybe
should just be an enum rather than a trait you implement... not sure why I made
it so general...)

----

Includes workaround for rustfmt issue.

Specifically, workaround rust-lang/rustfmt#3794 which
was causing CI's attempt to run `cargo fmt -- --check` to erroneously report:

```
% cargo fmt -- --check
error[E0583]: file not found for module `meta_build`
  --> /private/tmp/cbr/tests/cli.rs:11:20
   |
11 |     pub(crate) mod meta_build;
   |                    ^^^^^^^^^^
   |
   = help: name the file either meta_build.rs or meta_build/mod.rs inside the directory "/private/tmp/cbr/tests/cli/cli"

error[E0583]: file not found for module `command_invocation`
  --> /private/tmp/cbr/tests/ice.rs:34:20
   |
34 |     pub(crate) mod command_invocation;
   |                    ^^^^^^^^^^^^^^^^^^
   |
   = help: name the file either command_invocation.rs or command_invocation/mod.rs inside the directory "/private/tmp/cbr/tests/ice/common"

```

----

Includes fix for oversight in my cli test system: it needed to lookup target
binary, not our PATH.

(This functionality is also available via other means, such as
`$CARGO_BIN_EXE_<name>` and https://crates.io/crates/assert_cmd. I opted not to
use the builtin env variable because that is only available in very recent cargo
versions, and I would prefer our test suite to work peven on older versions of
cargo, if that is feasible...)

----

Includes applications of rustfmt suggestions, as well as an expansion of a
comment in a manner compatible with rustfmt.

(Namely, that replaced an inline comment which is erroneously deleted by rustfmt
(see rust-lang/rustfmt#2781 ) with an additional note
in the comment above the definition.)
@topecongiro
Copy link
Contributor

This issue will be fixed in 2.0.

unageek added a commit to unageek/graphest that referenced this issue Aug 25, 2021
@unageek
Workaround for rust-lang/rustfmt#3794
6347546
unageek added a commit to unageek/graphest that referenced this issue Aug 25, 2021
@unageek
Regression testing of graphs (#236)
5b8cb06 
* Regression testing of graphs

* Move test cases into a file

* Workaround for rust-lang/rustfmt#3794
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@pnkfelix @Marwes @rchaser53 @topecongiro