Dealing with comments, and more specifically, around keywords

[fee1-dead]

There's a rustfmt PR that I started a while ago that hasn't received much traction since it was marked blocked pending t-style's decision. To my understanding, there have been these concerns:

• Are there places for comments that should be discouraged or disallowed by the style guide?
• If the answer to the first question is "Yes", then should an automatic formatter delete those comments by default, provide a warning, or keep it without warning?
• If the placement of certain comments are neither explicitly encouraged or discouraged, should an automatic formatter delete or keep those comments by default?

This has been discussed on Zulip previously. AFAIK there were no "official" decisions that came out of the discussion, so I'd like to formally raise an issue here.

I realize that some of these questions above feel somewhat out of scope, and I just wanted to make it clear that "this is not within the scope of t-style" is a totally appropriate response. _{I really just want to unblock my PR, since it is really elegant..}

Here's also a small example:

pub // a
macro // b
hi(
    // c
) {
    // d
}

macro_rules! // a
my_macro {
    () => {};
}

Is currently formatted by rustfmt as:

pub macro hi(
    // c
) {
    // d
}

macro_rules! my_macro {
    () => {};
}

Deleting the comments. cc @rust-lang/rustfmt

[joshtriplett]

Speaking for myself here: I don't think there are any circumstances under which rustfmt should ever delete a comment.

[compiler-errors]

Yeah, also speaking as an individual: I think rustfmt deleting any comments is a bug. If there are positions that we want to especially discourage comments, rustfmt can move them instead. I also think that comments can be moved as part of formatting lines or fixing indentation.

[calebcartwright]

This was discussed in our meeting today, very brief summary:

• I agree, deleting comments is undesirable behavior and can be viewed as a bug (though the severity of the bug and the priority of fixing it remain under the purview of the rustfmt team)
• We're going to update the style guide text to provide some more concrete guidance on this subject, particularly as it relates to expectations of behavior for formatters implementing the style guide. we anticipate this will include a general overarching posture, as well as some likely modifications to specific existing text to eliminate any ambiguities