Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

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

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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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