Newlines make diagnostic fix suggestions render strangely

[compiler-errors]

Given the following code: playground

fn foo() -> bool {
    &
    if true { true } else { false }
}

The current output is:

error[E0308]: mismatched types
 --> src/lib.rs:2:5
  |
1 |   fn foo() -> bool {
  |               ---- expected `bool` because of return type
2 | /     &
3 | |     if true { true } else { false }
  | |___________________________________^ expected `bool`, found `&bool`
  |
help: consider removing the borrow
  |
2 -     &
2 +     if true { true } else { false }

What's wrong

The suggestion looks weird, seeming to suggest removing & and replacing it with a duplicate of the line that follows it.

The actual fixup'd code (via cargo fix) isn't actually broken. cargo fix does the change as expected, removing just the &. So this leads me to believe this is instead just a bug in the code that renders suggestions.

@camelid spotted this in #91545 but this is not related to that PR.

[camelid]

cc @estebank -- I think you wrote the code that generates these diffs?

[estebank]

I did. I guess what we could do is detect this case in particular and show only the 2 - & part. Alternatively, that + should instead be ~.

[camelid]

@rustbot claim

Perhaps I'll try this out :)

Which part of the code would need to be changed to only show the - & line?

[compiler-errors]

@camelid I bet the code is somewhere around here https://github.com/rust-lang/rust/blob/master/compiler/rustc_errors/src/emitter.rs#L1671

haven't looked much into the rendering, but a theory: is_multiline might be wrong for removal suggestions that end in \n.

Otherwise maybe we just need to suppress emitting + on the line following any time we render a removal suggestion ending in in \n.

[camelid]

@compiler-errors Thanks for the suggestion! I tried trimming newlines before calling is_multiline, which didn't seem to help, so I think it may be elsewhere.

Some results from investigating:

The span for the substitution with "" is 2:5 (line 2, col. 5) through 3:5. So the source range doesn't actually end in a newline; it ends in spaces for indentation on the next line. Then I think line 3 is computed as the line to display as being added (which makes sense given the output), though I'm still not sure why.