the inability to comment every non-obnoxious token without leftover whitespace before or after

[Paladynee]

Take any piece of Rust code, split by non-obnoxious tokens on each line, for each line add a space after the token, a newline, and a comment.
non-obnoxious token would mean tokens that make sense to be commented, e.g. all tokens other than commas, double colons :: in paths or dots in field access or method calls ., or < and > in generic argument syntax etc.

for example this code:

pub trait Clean<Inner, Outer>: Dirty + 'static {
    const ASSOC: usize = 0;
}

would become

pub 
// comment
trait 
// comment
Clean< 
// comment
Inner, 
// comment
Outer>: 
// comment
Dirty + 
// comment
'static { 
// comment
const 
// comment
ASSOC: 
// comment
usize = 
// comment
0; 
// comment
}

(note the whitespace before newlines)

the reason we do this is to see which tokens leave leftover whitespace after them when passed through rustfmt. these are all locations a programmer would possibly want to comment on, for example, one could need to add a comment between pub and trait to denote why Clean needs to be a trait and not a standalone constant (first error), or simply comment on the type of a constant (8th error) etc.

in contemporary rustfmt this cannot be formatted due to left behind trailing whitespace errors:

eurydice@fedora:~/coreign/thread_local_rng$ cargo fmt
error[internal]: left behind trailing whitespace
  --> /home/eurydice/coreign/thread_local_rng/src/lib.rs:22:22:4
   |
22 | pub 
   |    ^
   |

error[internal]: left behind trailing whitespace
  --> /home/eurydice/coreign/thread_local_rng/src/lib.rs:24:24:6
   |
24 | trait 
   |      ^
   |

...

warning: rustfmt has failed to format. See previous 11 errors.

[Paladynee]

i would suggest the sanest way to format this snippet specifically is this:

pub
    // comment
    trait
// comment
Clean<
    // comment
    Inner,
    // comment
    Outer
>:
    // comment
    Dirty +
    // comment
    'static
{
    // comment
    const
        // comment
        ASSOC:
        // comment
        usize =
        // comment
        0;
    // comment
}

steps i've taken while formatting:

1. all comments have the same indentation as the thing below them
2. pub denotes the start of the declaration, so it is not indented extra.
3. pub and trait are separated by a comment, as such to make it not look like as if trait starts a new declaration we indent it +1.
4. because trait is already indented extra and there's a comment between trait and the Identifier, we split pub trait and the Identifier into another line, resetting the indentation to the indentation of pub.
5. because GenericParams have at least 1 commented GenericParam, the < introduces +1 indentation for whatever's inside and we split every commented GenericParam into a separate line
6. > ends the argument list and we indent -1
7. TypeParamBounds have at least 1 commented TypeParamBound inside so the : introduces +1 indentation for whatever's inside and we split every commented TypeParamBound into a separate line.
8. because we have indented TypeParamBounds, in order to discern between the trait body and the TypeParamBounds we put the { on a newline, which resets the indentation back to the indentation of pub
9. const starts a declaration so it is not indented extra.
10. const and the Identifier are separated by a comment, so in order to make Identifier not look like a lone Identifier sitting around we indent it +1.
11. Because the Type is on a different line due to being separated with the colon by a comment, we make it the same indentation as the Identifier, or +1 if Identifier hasn't been indented.
12. The 0; could be mistaken for a lone expression, and as the ConstantItem is still unfinished we indent it the same as the previous line.
13. The last comment is like an item, so it shares indentation with every other item.