Change:
When two diagnostic spans are of the same width/location (effectively the same) and only one of them has a label, the output is the same as for a single one. There's a corner case where having a zero-width span (which get's rendered as a 1-char-wide span) fall in the same place as a 1-char-wide span without a label, resulting in the following output: This should instead be
Happy to take this on if no one else has. It'll be my first time contributing to Rust.
that'd be awesome! The actual case that made the bug evident is being introduced in (if you look at ). The following is the code that turns small suggestions into an inline label: the following is the code where we account for zero-width spans and finally here is the logic for displaying spans, which is a bit verbose, but at least it has some comments that explain what is supposed to be going on (this is where I would expect the fix to consider zero-width spans as a 1 char wide span to be made) Feel free to reach out to anyone in the team either here or at https://rust- Please take a look at , which has a lot of relevant information on how to work with the codebase, particularly (usually, ).
Are you working on this? If not can I work on this issue? Thanks!
Hey Gargi, feel free to take it. I haven’t been able to take a look yet.
Are you working on this? Please let me know if I can work on this.
Hi yes I'm working on it. :) I will have a PR open by EOD today.
have you had a chance to work on this? Or would you like me to take over?
hey please feel free to take over. Thanks!
is there any reason to ever keep a zero width annotation with no label?
zero width annotations are not always zero width conceptually. They mark a place in between two characters, and are often used for suggestions to mark a place where we'll add code or by diagnostics to point at a place in between two tokens. Sometimes having a label doesn't increase the understanding of the error. In the example shown above, we have a suggestion to add in between the two characters and we also have the primary span pointing at the closing . Does that make sense?
yea it does, I need to do some more debugging and investigating but I think I'll be able to come up with a fix for this edge-case soon :)

Discussion:
// 6..7. This is degenerate input, but it's best to degrade // gracefully -- and the parser likes to supply a span like // that for EOF, in particular. if lo.col_display == hi.col_display && lo.line == hi.line { hi.col_display += 1; }

&& j > i                      // multiline lines). && p == 0  // We're currently on the first line, move the label one line down { <ins> // If we're overlapping with an un-labelled annotation with the same span // we can just merge them in the output if next.start_col == annotation.start_col && next.end_col == annotation.end_col && !next.has_label() { continue; } </ins> // This annotation needs a new line in the output. p += 1; break;

|                               - unclosed delimiter LL |         let _ = if true { LL |         }); <del> |           ^ |           | |           help: `}` may belong here </del> <ins> |           ^ help: `}` may belong here </ins> error: expected identifier, found `;` --> $DIR/issue-60075.rs:6:11

--> $DIR/issue-58856-1.rs:2:14 | LL |     fn b(self> <del> |         -    ^ |         |    | |         |    help: `)` may belong here </del> <ins> |         -    ^ help: `)` may belong here |         | </ins> |         unclosed delimiter error: aborting due to previous error

--> $DIR/ex3-both-anon-regions-both-are-structs-3.rs:7:11 | LL | fn foo(mut x: Ref) { <del> |               --- |               | |               this type is declared with multiple lifetimes... </del> <ins> |               --- this type is declared with multiple lifetimes... </ins> LL |     x.a = x.b; |           ^^^ ...but data with one lifetime flows into the other here

--> $DIR/issue-10636-2.rs:5:25 | LL |     option.map(|some| 42; <del> |               -         ^ |               |         | |               |         help: `)` may belong here </del> <ins> |               -         ^ help: `)` may belong here |               | </ins> |               unclosed delimiter error: expected expression, found `)`

--> $DIR/regions-variance-contravariant-use-covariant-in-second-position.rs:25:30 | LL | fn use_<'short,'long>(c: S<'long, 'short>, <del> |                          ---------------- |                          | |                          this type is declared with multiple lifetimes... </del> <ins> |                          ---------------- this type is declared with multiple lifetimes... </ins> ... LL |     let _: S<'long, 'long> = c; |                              ^ ...but data with one lifetime flows into the other here

--> $DIR/token-error-correct-3.rs:15:35 | LL |             callback(path.as_ref(); <del> |                     -             ^ |                     |             | |                     |             help: `)` may belong here </del> <ins> |                     -             ^ help: `)` may belong here |                     | </ins> |                     unclosed delimiter error: expected one of `.`, `;`, `?`, `}`, or an operator, found `)`