Single-line where clauses may be 1 character too long

[kpreid]

With default settings, rustfmt thinks the following code is formatted:

//-------1---------2---------3---------4---------5---------6---------7---------8---------9---------!
//34567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
impl<E> Tt for Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa where E: Tttttttttttttttttttttttttttttttttt1
{}

But the impl header is 101 characters long. If it is made any longer, rustfmt will correctly wrap it to the next line, but at this exact length, rustfmt uses single-line formatting when it shouldn't.

This may be related to #5321, which involves trait bounds but not where.

[ytmimi]

@kpreid is this the type of wrapping you're noticing?

input:

//-------1---------2---------3---------4---------5---------6---------7---------8---------9---------!
//34567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
impl<E> Tt for Bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb where E: Tttttttttttttttttttttttttttttttttt02
{}

output:

//-------1---------2---------3---------4---------5---------6---------7---------8---------9---------!
//34567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
impl<E> Tt for Bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb where
    E: Tttttttttttttttttttttttttttttttttt02
{
}

@calebcartwright based on the style guide rules for where clauses this kind of wrapping seems off to me.

I think I'd expect this to output something like:

//-------1---------2---------3---------4---------5---------6---------7---------8---------9---------!
//34567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
impl<E> Tt for Bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
where
    E: Tttttttttttttttttttttttttttttttttt02,
{
}

Additionally, where_single_line is set to false by default so I wouldn't expect rustfmt to try and place the entire where clause on a single line at all. Some of that inconsistency might be explained by #2741

[kpreid]

is this the type of wrapping you're noticing?

I didn't particularly investigate the case where it does wrap. I don't particularly care where the line breaks land, just that the result obeys the max width.