cargo fix - failure with Deserialize

[ExpHP]

cc @alexcrichton

Oh dear these issues sound bad! Are you sure you were testing with an up-to-date nightly? Recent changes in lint emissions should supress lints related to foreign macros (like derive in these cases) but if they’re still showing up that’s a bug!

Would you be able to share some test cases if it’s still showing problems?

---

#![feature(rust_2018_preview)]

extern crate serde;
#[macro_use]
extern crate serde_derive;

#[derive(Deserialize)]
pub struct Struct(::module::Thing);

mod module {
    #[derive(Deserialize)]
    pub struct Thing;
}

A complete source tree: deserialize-test-case.tar.gz

This test case will be "magically" fixed when the additions to the proc-macro crate wrapped by proc-macro2 become stable.

---

Output

warning: failed to automatically apply fixes suggested by rustc to crate `deserialize_test_case`

after fixes were automatically applied the compiler reported errors within these files:

  * src/lib.rs

This likely indicates a bug in either rustc or cargo itself,
and we would appreciate a bug report! You're likely to see 
a number of compiler warnings after this message which cargo
attempted to fix but failed. If you could open an issue at
https://github.com/rust-lang/cargo/issues
quoting the full output of this command we'd be very appreciative!

warning: absolute paths must start with `self`, `super`, `crate`, or an external crate name in the 2018 edition
 --> src/lib.rs:8:19
  |
8 | pub struct Struct(::module::Thing);
  |                   ^^^^^^^^^^^^^^^ help: use `crate`: `crate::module::Thing`
  |
  = 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 TBD

warning: absolute paths must start with `self`, `super`, `crate`, or an external crate name in the 2018 edition
 --> src/lib.rs:7:10
  |
7 | #[derive(Deserialize)]
  |          ^^^^^^^^^^^ help: use `crate`: `crate::Deserialize`
  |
  = 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 TBD

warning: absolute paths must start with `self`, `super`, `crate`, or an external crate name in the 2018 edition
 --> src/lib.rs:8:19
  |
8 | pub struct Struct(::module::Thing);
  |                   ^^^^^^^^^^^^^^^ help: use `crate`: `crate::module::Thing`
  |
  = 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 TBD

warning: absolute paths must start with `self`, `super`, `crate`, or an external crate name in the 2018 edition
 --> src/lib.rs:7:10
  |
7 | #[derive(Deserialize)]
  |          ^^^^^^^^^^^ help: use `crate`: `crate::Deserialize`
  |
  = 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 TBD

    Finished dev [unoptimized + debuginfo] target(s) in 0.68s

Tested on rustc 1.29.0-nightly (6a1c0637c 2018-07-23)

[alexcrichton]

Thanks for the report! Unfortunately this is a case that won't be fixed with an update to various crates, the issue here is:

• First, the ::module::Thing path should be using a crate-relative path, and rustc warns about this with a correct suggestion.
• Next, presumably somewhere in the generated code of #[derive(Deserialize)], it also mentions the path the user has written down, as ::module::Thing. This is also warned against as it needs a fix, but the span information here is incorrect. That means the suggestion becomes nonsensical (crate::Deserialize in derive)

The bug here is that the compiler is marking the second suggestion as automatically fixable, when it's not. I'll look into that.

[alexcrichton]

I've confirmed this is fixed by rust-lang/rust#52756, so I'm going to close in favor of that.