trait bounds with comments are not formatted

[gnzlbg]

This compiles file:

pub trait A {}
pub trait B {}
pub trait C {}

pub trait Foo:
// A and C
A + C
// and B
    + B
{}

but rustfmt formats it into this:

pub trait Foo: A + C + B // A and C
A
    + C
// and B
    + B {
}

try this live (just click on Format in the playground)

which fails to compile with:

   Compiling playground v0.0.1 (file:///playground)
error: expected one of `(`, `+`, `::`, `<`, `where`, or `{`, found `A`
 --> src/main.rs:6:1
  |
5 | trait Foo: A + C + B // A and C:
  |                     - expected one of `(`, `+`, `::`, `<`, `where`, or `{` here
6 | A + C
  | ^ unexpected token

[topecongiro]

To fix this, we need to extract comments between

1. Foo and :
2. : and the first trait bound
3. each trait bound and +

...which is, a lot of work. I hope that in the future we generalize write_list() and use it to rewrite trait bounds. For now, I think we should just return the original code if there are comments that we cannot handle.

[gnzlbg]

Would this be easier if rustfmt wouldn't reorder the trait bounds at all?

(that is, keep the trait bounds in the declared order, align them properly, put one per line, etc, but don't reorder them)

[nrc]

Would this be easier if rustfmt wouldn't reorder the trait bounds at all?

No, not really, the hard bit is processing the source, rather than formatting the output

[nrc]

This is now somewhat addressed. We no longer corrupt the trait bounds, but we don't do any formatting at all if there are comments.

[gnzlbg]

Thanks @nrc :) step by step!

…

On Fri 10. Nov 2017 at 22:20, Nick Cameron ***@***.***> wrote: This is now somewhat addressed. We no longer corrupt the trait bounds, but we don't do any formatting at all. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2055 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3NpqtR8gVrbvUeRq9Vu7IDmS1fPoPcks5s1L4JgaJpZM4P1j9I> .

[davidBar-On]

PR #4666 enhance the resolution of this issue by handling comments between the Trait Generics and Bounds, e.g. the // A and C comment in the issue description. The PR does not handle comments withing the Bounds, e.g. the // and B in the description, which probably will be solved by handling BinOp comments.