[Issue #4108] post_comment_alignment config option

[Ripper53]

Issue

Add config to format like from this issue: #4108

Currently, this code:

fn foo(
    a: usize, // Meow
    b: f32, // Bark
) {
}

Is formatted into this:

fn foo(
    a: usize, // Meow
    b: f32,   // Bark
) {
}

This can confuse the reader into thinking that the two comments are related or follow each other, even when they are unrelated.

Add a configuration option to allow code to be formatted with one space between the code and comment.

Changes

Add a config option of post_comment_alignment that has two options:

1. SingleSpace
2. SameIndent

The SingleSpace behavior adds one space between the code and comment.
The SameIndent behavior keeps each item in the item list aligned. This does not preserve the behavior from before, because it was inconsistent. For example, the new implementation fixes this issue: #4108 (comment)

I have edited preexisting tests to match the behavior of the new default option SingleSpace.

write_list now takes a concrete type of Vec<T> and takes ownership, which allows the use of iter and into_iter without cloning unlike the previous solution.

Removed align_comments from ListFormatting struct. It was previously used to figure out if a comment should be aligned or not, but now the new config option is used.

Discussion

I believe there should be a structure that is the single source of truth about the transformations of a comment. For example, how do we know if a comment should be turned into block style or wrapped? Right now, that logic exists in more than a single place, for example, in my rewrite of the write_list function and in the preexisting rewrite_comment function.

More general discussion:
I also do not like the use of primitive types everywhere. For example, a comment is treated and passed around as &str, when it could easily be a newtype. So could comment openers and line starters. Plus, I don't think boolean parameters should be used at all in function parameters. Even for configuration, I would prefer a newtype like so:

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub struct NormalizeComments(bool);
impl NormalizeComments {
    pub fn enabled() -> Self {
        Self(true)
    }
    pub fn disabled() -> Self {
        Self(false)
    }
    pub fn is_enabled(&self) -> bool {
        self.0
    }
}

Then, functions like commen_style can change their boolean parameter to NormalizeComments:

pub(crate) fn comment_style(orig: &str, normalize_comments: NormalizeComments) -> CommentStyle<'_> {
    ...
}

Call site looks much more readable:

comment_style(orig, NormalizeComments::enabled())

vs.

comment_style(orig, true)

This also reduces the likelihood of logic errors with the incorrect boolean being supplied to the function. The newtype NormalizeComments is a helpful abstraction that carries meaning with it instead of being a generic boolean that can be mixed and matched with other booleans.

[ytmimi]

I don't think it makes sense to support a bespoke fn_post_comment_alignment option just yet. It might make more sense to start with something more general to control post comment alignment in any list of items. For example, fn parameters, function call arguments, array literals, tuples, struct fields, etc.