rustfmt overwriting other files with contents of target file

[jonhoo]

After upgrading to d3eba76e4d63c08fa0c4406745d1f0cc0e576758, I'm seeing some truly bizarre (and quite disturbing) behavior of rustfmt. Specifically, when I format a particular file in my project, rustfmt overwrites a bunch of other files with the contents of that file! A console example will likely be most helpful:

$ rustfmt --version
0.6.3 (d3eba76)
$ cargo b
   Compiling xxx v0.1.0 (file:///home/jon/dev/projects/xxx)
    Finished debug [unoptimized + debuginfo] target(s) in 3.97 secs
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
$ diff -q benchmarks/targets/memcached.rs benchmarks/vote.rs 
Files benchmarks/targets/memcached.rs and benchmarks/vote.rs differ
$ rustfmt benchmarks/vote.rs 
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   benchmarks/targets/memcached.rs

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	benchmarks/targets/memcached.rs.bk

no changes added to commit (use "git add" and/or "git commit -a")
$ diff -q benchmarks/targets/memcached.rs benchmarks/vote.rs
$

This is a somewhat large codebase that isn't public (yet), and so I unfortunately can't point you at the source. The basic structure is as follows though:

$ cat Cargo.toml 
...
[features]
b_memcached = ["memcache"]
...
[lib]
name = "xxx"
path = "src/lib.rs"
...
[[bin]]
name = "vote"
path = "benchmarks/vote.rs"
$ ls -laR benchmarks/
drwxr-xr-x 1 jon users    92 Nov 25 12:56 targets/
-rw-r--r-- 1 jon users 10598 Nov 25 12:53 vote.rs

benchmarks/targets:
-rw-r--r-- 1 jon users 1900 Nov 25 12:56 memcached.rs
-rw-r--r-- 1 jon users  524 Nov 25 12:47 mod.rs
$ grep -EB1 '^mod ' benchmarks/vote.rs 

mod targets;
$ grep -EB1 '^pub mod ' benchmarks/targets/mod.rs 
...
#[cfg(feature="b_memcached")]
pub mod memcached;

The other files that are overwritten are all of the same form as benchmarks/targets/memcached.rs (i.e., they are compiled under a #[cfg(feature = ...)] directive). I have other modules that work the same way, but that are not conditionally compiled, and they are not overwritten by rustfmt.

[jonhoo]

git bisect shows that d3eba76 introduced the bug (which isn't great given the size of that commit)

[nrc]

Thanks for the bug report. If you could make a minimal test case that reproduces the behaviour that would be extremely helpful. Do you get the same behaviour running rustfmt on other files, or only that one (or some subset of files)?

[jonhoo]

$ ls -R
.:
foo.rs  targets/

./targets:
bar.rs  mod.rs
$ cat foo.rs 
mod targets;

fn main() {}
$ cat targets/mod.rs 
#[cfg(feature="bar")]
pub mod bar;
$ cat targets/bar.rs 
fn lib() {}
$ rustfmt foo.rs 
$ cat targets/bar.rs 
mod targets;

fn main() {}

[jonhoo]

Re your question: I remember seeing it on one other file, but can't remember what that was. I thought it was just a fluke at the time, so did a swift git checkout -p.

[jonhoo]

Note also that this does not trigger if the mod statement with the cfg directive is included directly in foo.rs. The indirection through targets/mod.rs is necessary.

[jonhoo]

I keep forgetting this, and am constantly finding myself having to do a git checkout targets/*.rs (which is, in and of itself, upsetting, as it may overwrite changes). Can anyone else reproduce the bug with my example above?

[mathstuf]

I am able to reproduce the error here. Using rustfmt as of 56469a8.

[jonhoo]

Still present in 0.7.0

[nrc]

I investigated this today, it is due to cfg'ed modules being stripped in the parser (rust-lang/rust#36482). This will need a fix in rustc and that will need to propagate to Syntex before it can have an effect in Rustfmt, but hopefully a fix should be coming up soon-ish. In the meantime, work-around is to ensure all cfgs resolve to true, or comment them out.

[jonhoo]

@nrc Ah, good catch! That's a pretty painful work-around, but I guess there's not that much we can do about it until a fix percolates down the chain.

[nrc]

cc rust-lang/rust#39145

[dtolnay]

Syntex 0.56.0 contains the fix from rust-lang/rust#39145.

[jonhoo]

@nrc I tried just bumping syntex to 0.56.2 and build rustfmt locally to see if the problem would be fixed that way, but (perhaps obviously) it didn't build due to various type changes. I guess we're a decent number of commits behind syntex (0.52 vs 0.56), so this isn't too surprising.