cargo fix doesn’t fix path dependencies

[SimonSapin]

In an empty directory, run:

cargo new --lib a
cargo new --lib b
cargo new --lib a/c
echo 'b = {path = "../b"}' >> a/Cargo.toml
echo 'c = {path = "./c"}' >> a/Cargo.toml
cat > a/src/lib.rs <<END
pub fn foo() {}

pub mod bar {
    use foo;
    pub fn baz() { foo() }
}
END
cp a/src/lib.rs b/src/lib.rs
cp a/src/lib.rs a/c/src/lib.rs
(cd a && cargo +nightly fix --edition -j1)
find -name lib.rs | xargs grep use
rm -r a b

This creates three crates with identical code, with one depending on the other two through path Cargo dependencies. cargo fix is able to silently fix the "root" crate, for the other two it only prints warnings.

Output with nightly-2018-11-01 which contains cargo 1.31.0-nightly (2d0863f65 2018-10-20) which depends on rustfix = "0.4.2":

     Created library `a` project
     Created library `b` project
     Created library `a/c` project
    Checking b v0.1.0 (/tmp/foo/b)                                                                                     
warning: absolute paths must start with `self`, `super`, `crate`, or an external crate name in the 2018 edition        
 --> /tmp/foo/b/src/lib.rs:4:9                                                                                         
  |                                                                                                                    
4 |     use foo;                                                                                                       
  |         ^^^ help: use `crate`: `crate::foo`                                                                        
  |                                                                                                                    
  = note: `-W absolute-paths-not-starting-with-crate` implied by `-W rust-2018-compatibility`                          
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2018 edition!
  = note: for more information, see issue #53130 <https://github.com/rust-lang/rust/issues/53130>                      
                                                                                                                       
    Checking c v0.1.0 (/tmp/foo/a/c)                                                                                   
warning: absolute paths must start with `self`, `super`, `crate`, or an external crate name in the 2018 edition        
 --> c/src/lib.rs:4:9                                                                                                  
  |                                                                                                                    
4 |     use foo;                                                                                                       
  |         ^^^ help: use `crate`: `crate::foo`                                                                        
  |                                                                                                                    
  = note: `-W absolute-paths-not-starting-with-crate` implied by `-W rust-2018-compatibility`                          
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2018 edition!
  = note: for more information, see issue #53130 <https://github.com/rust-lang/rust/issues/53130>                      
                                                                                                                       
    Checking a v0.1.0 (/tmp/foo/a)                                                                                     
      Fixing src/lib.rs (1 fix)                                                                                        
    Finished dev [unoptimized + debuginfo] target(s) in 0.44s                                                          
./b/src/lib.rs:    use foo;
./a/c/src/lib.rs:    use foo;
./a/src/lib.rs:    use crate::foo;

[Nemo157]

Alternatively

cargo +nightly new --edition 2015 --lib a
cargo +nightly new --edition 2015 --lib b
cargo +nightly new --edition 2015 --lib a/c
cat >> a/Cargo.toml <<END
b = {path = "../b"}
c = {path = "./c"}
[workspace]
members = [".", "./c"]
END
cat > a/src/lib.rs <<END
pub fn foo() {}

pub mod bar {
    use foo;
    pub fn baz() { foo() }
}
END
cp a/src/lib.rs b/src/lib.rs
cp a/src/lib.rs a/c/src/lib.rs
(cd a && cargo +nightly fix --edition -j1 --all)
find -name lib.rs | xargs grep use
rm -r a b

Fixes both a and a/c, it seems to me like the bug is that it's showing the edition warnings for dependencies that it's not migrating. I wouldn't expect it to migrate path dependencies outside the current workspace automatically.

[steveklabnik]

This should probably be filed against Cargo, given that's where cargo fix lives these days.

[alexcrichton]

Yes this is largely a Cargo issue rather than a rustfix one, and agreed that warnings should only be presented for crates which are actually considered candidates for fixing!

[alexcrichton]

This should be fixed in #6247

[SimonSapin]

Silencing migration warnings for crates that are not being fixed is a nice improvement, but it doesn’t fix the issue that path dependencies are not fixed.

[alexcrichton]

You can migrate multiple crates manually with -p flags I believe, but otherwise crates aren't migrated wholesale and just one at a time

[SimonSapin]

Yes they aren’t, and I think that’s a bug.

[killercup]

@steveklabnik did you mean to close that from your fork of cargo?

[steveklabnik]

uh, no. Sorry about that. All I did was the usual "update my fork of cargo and push master". It shouldn't be closing random things...

[ehuss]

I'm uncertain, but I think I'm going to propose to close this. I think there are some complications with implicitly affecting path dependencies (like with patches and such), and also that would deviate quite a bit from how other cargo commands work. I'm not sure if it is really a good idea to implicitly affects path dependencies. Ideally in that scenario, using a workspace would be better.

[weihanglo]

using a workspace would be better.

Agree on this approach. Path dependencies can also be shared across workspaces and not belong to any of them. Fixing them sounds risky and not always intented.

Closing as proposed.