Multiline highlights in diagnostic get noisy quickly #38246
Comments
|
I understand that there're some cases where highlighting the first char of the span as it was done before would be less noisy. I think that those cases can still be identified and select the desired output span (only the first line always) specifically and leave multiline output by default. I wonder if the I'm also thinking that situations where the span starts and ends in the first char of the line (or that have only whitespace before the start of the span) could lend themselves to something like: |
|
@estebank, I think the highlights as they are used currently are great when the beginning and end of the highlight are important; but they are less useful when whole blocks are being highlighted, and the error/warning does not refer to a scope. For example, when the dead code lint marks a whole function as unused, it is currently shown as this: Or, for a one-liner function: I think it might make sense to just highlight the lines, like (please bikeshed): I can see that it might be difficult to differentiate when to show "scope markers" and when not to. |
|
For the cases of function never used, I'd prefer to see something like For cases where the entire multispan is actually needed, I wonder if we can just forego the highlighting and do the following, maybe changing the color of the or maybe, avoiding overloading meaning and reducing the special case presentation: This would only be done when there's only 1 span, it is a multiline span and there's only whitespace before the beginning of the fist line and after the end of the last line. Thoughts? |
|
@estebank great ideas! Actually just highlighting the method name will probably suffice. Many of these cases will probably work far better when highlighting much less, but more specific code :) |
|
Yup, definitely 👍 for highlighting just the name if you mean the whole thing. There's another case that came up recently where we show the mismatch in the call and the definition. In that case we may where we want to show the function signature, we could also highlight the name and the parameters. I think either of those requires adding some more span information to the declarations. |
|
@jonathandturner do you think it is better to just add a Span field to the struct called something along the lines of |
steveklabnik
added
the
A-diagnostics
steveklabnik
added
the
T-compiler
…nkov
Add a way to get shorter spans until `char` for pointing at defs
```rust
error[E0072]: recursive type `X` has infinite size
--> file.rs:10:1
|
10 | struct X {
| ^^^^^^^^ recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `X` representable
```
vs
```rust
error[E0072]: recursive type `X` has infinite size
--> file.rs:10:1
|
10 | struct X {
| _^ starting here...
11 | | x: X,
12 | | }
| |_^ ...ending here: recursive type has infinite size
|
= help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `X` representable
```
Re: rust-lang#35965, rust-lang#38246. Follow up to rust-lang#38328.
r? @jonathandturner
Reduce visual clutter of multiline start when possible
When a span starts on a line with nothing but whitespace to the left,
and there are no other annotations in that line, simplify the visual
representation of the span.
Go from:
```rust
error[E0072]: recursive type `A` has infinite size
--> file2.rs:1:1
|
1 | struct A {
| _^ starting here...
2 | | a: A,
3 | | }
| |_^ ...ending here: recursive type has infinite size
|
```
To:
```rust
error[E0072]: recursive type `A` has infinite size
--> file2.rs:1:1
|
1 | / struct A {
2 | | a: A,
3 | | }
| |_^ recursive type has infinite size
```
Re: #38246.
r? @nikomatsakis CC @jonathandturner
|
Closing as per #41214 (comment). |
This code (playground)
generates these diagnostic messages:
Especially the markers on the struct are making it pretty weird to read/recognize the code. (Colored output makes it a bit easier to differentiate the code symbols from the diagnostics ascii art though! 😄)
There probably are some opportunities to make concrete errors highlight more specific parts of the code. Sadly, this only gets worse for less straightforward code. Here's an example from an error I recently saw while fiddling with a macro in diesel:
This would require highlighting both
'as, right?cc @estebank who worked on #37369
The text was updated successfully, but these errors were encountered: