rust/tests/ui/malformed/issue-107423-unused-delim-only-one-no-pair.stderr

error: this file contains an unclosed delimiter
  --> $DIR/issue-107423-unused-delim-only-one-no-pair.rs:7:11
   |
LL | fn a(){{{
   |       ---^
   |       |||
   |       ||unclosed delimiter
   |       |unclosed delimiter
   |       unclosed delimiter

error: aborting due to 1 previous error
don't point at nonexisting code beyond EOF when warning about unused delims Previously we would show this: ``` warning: unnecessary braces around block return value --> /tmp/bad.rs:1:8 \| 1 \| fn a(){{{ \| ^ ^ \| = note: `#[warn(unused_braces)]` on by default help: remove these braces \| 1 - fn a(){{{ 1 + fn a(){{ \| ``` which is now hidden in this case. We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing. This would cause the debug assertion ice to trigger. I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :( But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable. Fixes https://github.com/rust-lang/rust/issues/107423 r? @compiler-errors 2023-02-04 06:27:53 -06:00			`error: this file contains an unclosed delimiter`
			`--> $DIR/issue-107423-unused-delim-only-one-no-pair.rs:7:11`
			`\|`
			`LL \| fn a(){{{`
Be more accurate about calculating `display_col` from a `BytePos` No longer track "zero-width" chars in `SourceMap`, read directly from the line when calculating the `display_col` of a `BytePos`. Move `char_width` to `rustc_span` and use it from the emitter. This change allows the following to properly align in terminals (depending on the font, the replaced control codepoints are rendered as 1 or 2 width, on my terminal they are rendered as 1, on VSCode text they are rendered as 2): ``` error: this file contains an unclosed delimiter --> $DIR/issue-68629.rs:5:17 \| LL \| ␜␟ts␀![{i \| -- unclosed delimiter \| \| \| unclosed delimiter LL \| ␀␀ fn rݻoa>rݻm \| ^ ``` 2024-07-09 12:00:19 -05:00			`\| ---^`
don't point at nonexisting code beyond EOF when warning about unused delims Previously we would show this: ``` warning: unnecessary braces around block return value --> /tmp/bad.rs:1:8 \| 1 \| fn a(){{{ \| ^ ^ \| = note: `#[warn(unused_braces)]` on by default help: remove these braces \| 1 - fn a(){{{ 1 + fn a(){{ \| ``` which is now hidden in this case. We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing. This would cause the debug assertion ice to trigger. I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :( But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable. Fixes https://github.com/rust-lang/rust/issues/107423 r? @compiler-errors 2023-02-04 06:27:53 -06:00			`\| \|\|\|`
			`\| \|\|unclosed delimiter`
			`\| \|unclosed delimiter`
			`\| unclosed delimiter`

Show number in error message even for one error Co-authored-by: Adrian <adrian.iosdev@gmail.com> 2023-11-21 09:44:16 -06:00			`error: aborting due to 1 previous error`
don't point at nonexisting code beyond EOF when warning about unused delims Previously we would show this: ``` warning: unnecessary braces around block return value --> /tmp/bad.rs:1:8 \| 1 \| fn a(){{{ \| ^ ^ \| = note: `#[warn(unused_braces)]` on by default help: remove these braces \| 1 - fn a(){{{ 1 + fn a(){{ \| ``` which is now hidden in this case. We would create a span spanning between the pair of redundant {}s but there is only EOF instead of the `}` so we would previously point at nothing. This would cause the debug assertion ice to trigger. I would have loved to just only point at the second delim and say "you can remove that" but I'm not sure how to do that without refactoring the entire diagnostic which seems tricky. :( But given that this does not seem to regress any other tests we have, I think this edge-casey enough be acceptable. Fixes https://github.com/rust-lang/rust/issues/107423 r? @compiler-errors 2023-02-04 06:27:53 -06:00