butchers cfg_attr attribute comment alignment

[matthiaskrgr]

Structs get nice comment alignment:

struct bla {
    aaa: u8, // commet
    bbbbbbbbbbbbbbbbb: u8, // comment
    c: u8, // comment
    dee: u8, // comment
}

becomes

struct bla {
    aaa: u8,               // comment
    bbbbbbbbbbbbbbbbb: u8, // comment
    c: u8,                 // comment
    dee: u8,               // comment
}

however if we have some nicely aligned attribute comments as seen in cargo for example:

#![cfg_attr(feature = "cargo-clippy", allow(boxed_local))]             // bug rust-lang-nursery/rust-clippy#1123
#![cfg_attr(feature = "cargo-clippy", allow(cyclomatic_complexity))]   // large project
#![cfg_attr(feature = "cargo-clippy", allow(derive_hash_xor_eq))]      // there's an intentional incoherence
#![cfg_attr(feature = "cargo-clippy", allow(explicit_into_iter_loop))] // (unclear why)
#![cfg_attr(feature = "cargo-clippy", allow(explicit_iter_loop))]      // (unclear why)
#![cfg_attr(feature = "cargo-clippy", allow(identity_op))]             // used for vertical alignment
#![cfg_attr(feature = "cargo-clippy", allow(implicit_hasher))]         // large project
#![cfg_attr(feature = "cargo-clippy", allow(large_enum_variant))]      // large project
#![cfg_attr(feature = "cargo-clippy", allow(redundant_closure_call))]  // closures over try catch blocks
#![cfg_attr(feature = "cargo-clippy", allow(too_many_arguments))]      // large project
#![cfg_attr(feature = "cargo-clippy", allow(type_complexity))]         // there's an exceptionally complex type
#![cfg_attr(feature = "cargo-clippy", allow(wrong_self_convention))]   // perhaps Rc should be special cased in Clippy?

rustfmt completely butchers the alignment :(

#![cfg_attr(feature = "cargo-clippy", allow(boxed_local))] // bug rust-lang-nursery/rust-clippy#1123
#![cfg_attr(feature = "cargo-clippy", allow(cyclomatic_complexity))] // large project
#![cfg_attr(feature = "cargo-clippy", allow(derive_hash_xor_eq))] // there's an intentional incoherence
#![cfg_attr(feature = "cargo-clippy", allow(explicit_into_iter_loop))] // (unclear why)
#![cfg_attr(feature = "cargo-clippy", allow(explicit_iter_loop))] // (unclear why)
#![cfg_attr(feature = "cargo-clippy", allow(identity_op))] // used for vertical alignment
#![cfg_attr(feature = "cargo-clippy", allow(implicit_hasher))] // large project
#![cfg_attr(feature = "cargo-clippy", allow(large_enum_variant))] // large project
#![cfg_attr(feature = "cargo-clippy", allow(redundant_closure_call))] // closures over try catch blocks
#![cfg_attr(feature = "cargo-clippy", allow(too_many_arguments))] // large project
#![cfg_attr(feature = "cargo-clippy", allow(type_complexity))] // there's an exceptionally complex type
#![cfg_attr(feature = "cargo-clippy", allow(wrong_self_convention))] // perhaps Rc should be special cased in Clippy?

[nrc]

is this with the default options?

[matthiaskrgr]

yes

[calebcartwright]

I'm actually going to close this because it is a combination of correct/expected default behavior in the case of the comments after the attributes, and a known/existing bug on the incorrect default-vertical alignment of comments on the struct (which happens in some other item contexts too refs #4108).

If the underlying ask is for producing visual/vertical alignment of comments in this type of context, that's going to be a bit of a stretch. Whether that's something that needs a holistic solution or has to be addressed on a case by case basis (e.g. creating some new representation of line break delimited inner attributes), but I think that'd be best served as a separate investigation and not on a known bug