Inconsistent formatting of attributes

[osa1]

In this struct:

struct Test {
    /// foo
    #[serde(default)]
    pub join: Vec<String>,
    #[serde(default)] pub tls: bool,
}

Both fields have the same attribute but they're formatted differently, because of the comment line in the first one.

[nrc]

Hmm, I assume this isn't a problem with a non-doc comment? Doc comments are treated like attributes, so I think this is formatted like join has two attributes and thus they get stacked.

I think we might just want to change the default formatting for attributes on fields to be vertical rather than inline.

[osa1]

I assume this isn't a problem with a non-doc comment?

Correct, if I make the comment line non-doc they're both formatted the same (attributes and fields on the same line).

[vishalsodani]

@nrc I looked at this. Seems we just need to change a parameter to false in the config.rs.

same_line_attributes: bool, false, false

But many tests fail on this change which will have to be fixed.

[nrc]

Seems we just need to change a parameter to false in the config.rs.

That would change the default to always vertical attributes, yeah. I'm not 100% sure we want that, but I think we probably do. The test fallout is expected with any option default change.

If you wanted to take this on, I think it would be good to change the default and fix the tests and see what it looks like.

[vishalsodani]

@nrc I have fixed all the tests. But there is one test related to #1046 which seems redundant now and could be removed.

[nrc]

@vishalsodani ah, hmm, perhaps this is more interesting to fix. Within an enum variant or tuple struct, then I think attributes should be on the same line, but on fields in a struct they should be on different lines. I think it is probably worth removing same_line_attributes altogether, find its uses and hard-wire true or false depending on whether it is a tuple field or a 'proper' field.

[RReverser]

@nrc Now that same_line_attributes is gone, there seems to be no easy way to workaround #2389 (comment). More generally, may I ask why it can't be an option? Personally I prefer to always put attributes on its own line to separate it from an actual important item.