Skip to content

cargo fix: Paths in attributes aren't automatically converted #5795

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.

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

Closed
jtgeibel opened this issue Jul 26, 2018 · 2 comments
Closed

cargo fix: Paths in attributes aren't automatically converted #5795

jtgeibel opened this issue Jul 26, 2018 · 2 comments

Comments

@jtgeibel
Copy link
Member

While trying out cargo fix I ran into the following scenario that isn't automatically converted. On the most recent nightly cargo 1.29.0-nightly (506eea76e 2018-07-17), the serde attribute on the struct below isn't converted and causes the automated rewrite to bail on the affected file. I don't necessarily expect it to be able to fix this code, but it was difficult to determine what this issue was when there were many other warnings in the original code (so many that the intro message identifying the problem files scrolled out of my terminals buffer).

Cargo.toml

[package]
name = "cargo-fix-test"
version = "0.1.0"
authors = ["Justin Geibel <...>"]

[dependencies]
serde = "1"
serde_derive = "1"

src/lib.rs

#![feature(rust_2018_preview)]

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

mod a {
    #[derive(Serialize)]
    pub struct A (
        // the path in the following attribute causes issues
        #[serde(with = "::b")]
        pub u8,
    );
}

mod b {
    pub fn serialize<S>(_num: &u8, serializer: S) -> Result<S::Ok, S::Error>
    where
        S: serde::Serializer,
    {
        serializer.serialize_str(&"some u8")
    }
}

cargo fix Output

$ cargo fix --prepare-for 2018 --allow-dirty
    Checking cargo-fix-test v0.1.0 (file:///home/jtgeibel/repos/localhost/tmp/cargo-fix-test)                                                                                                                                                                                  
warning: failed to automatically apply fixes suggested by rustc to crate `cargo_fix_test`

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:14
  |
8 |     #[derive(Serialize)]
  |              ^^^^^^^^^ help: use `crate`: `crate::Serialize`
  |
  = 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

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

The following patch allows cargo fix to complete cleanly.

@@ -5,10 +5,11 @@ extern crate serde_derive;
 extern crate serde;
 
 mod a {
+    use b;
+
     #[derive(Serialize)]
     pub struct A (
-        // the path in the following attribute causes issues
-        #[serde(with = "::b")]
+        #[serde(with = "b")]
         pub u8,
     );
 }
@alexcrichton
Copy link
Member

Thanks for the report! I believe this is the same issue as #5799 (comment) where cargo fix is erroneously attempting to fix what it should not.

I believe this message should be fixed by rust-lang/rust#52756

@alexcrichton
Copy link
Member

For now though I'm going to close in favor of #5799 which I believe is basically the same as this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants