| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Use more slice patterns inside the compiler
Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'.
r? ghost
|
|
Split `ColorConfig` off of `HumanReadableErrorType`
The previous setup tied two unrelated things together. Splitting these two is a better model.
Identified by https://github.com/rust-lang/rust/pull/126597/files#r1667800754
|
|
|
|
The previous setup tied two unrelated things together. Splitting these two is a better model.
|
|
Some `const { }` asserts for #128200
The correctness of code in #128200 relies on an array being sorted (so that it can be used in binary search later), which is currently enforced with `// tidy-alphabetical` (and characters being written in `\u{XXXX}` form), as well as lack of duplicate entries with conflicting keys, which is not currently enforced.
This PR changes it to using a `const{ }` assertion (and also checks for duplicate entries). Sadly, we cannot use the recently-stabilized `is_sorted_by_key` here, because it is not const (but it would not allow us to check for uniqueness anyways). Instead, let's write a manual loop.
Alternative approach (perfect hash function): #128463
r? `@ghost`
|
|
|
|
|
|
|
|
On short error format, append primary span label to message
The `error-format=short` output only displays the path, error code and main error message all in the same line. We now add the primary span label as well after the error message, to provide more context.
|
|
|
|
assertion
|
|
The `error-format=short` output only displays the path, error code and
main error message all in the same line. We now add the primary span label
as well after the error message, to provide more context.
|
|
Change output normalization logic to be linear against size of output
Modify the rendered output normalization routine to scan each character *once* and construct a `String` to be printed out to the terminal *once*, instead of using `String::replace` in a loop multiple times. The output doesn't change, but the time spent to prepare a diagnostic is now faster (or rather, closer to what it was before #127528).
|
|
When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all.
Fix clippy lint suggestion incorrectly treated as `span_help`.
|
|
|
|
|
|
Scan strings to be normalized for printing in a linear scan and collect
the resulting `String` only once.
Use a binary search when looking for chars to be replaced, instead of a
`HashMap::get`.
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
We already point these out quite aggressively, telling people not to use them, but would normally be rendered as nothing. Having them visible will make it easier for people to actually deal with them.
```
error: unicode codepoint changing visible direction of text present in literal
--> $DIR/unicode-control-codepoints.rs:26:22
|
LL | println!("{:?}", '�');
| ^-^
| ||
| |'\u{202e}'
| this literal contains an invisible unicode text flow control codepoint
|
= note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen
= help: if their presence wasn't intentional, you can remove them
help: if you want to keep them but make them visible in your source code, you can escape them
|
LL | println!("{:?}", '\u{202e}');
| ~~~~~~~~
```
vs the previous
```
error: unicode codepoint changing visible direction of text present in literal
--> $DIR/unicode-control-codepoints.rs:26:22
|
LL | println!("{:?}", '');
| ^-
| ||
| |'\u{202e}'
| this literal contains an invisible unicode text flow control codepoint
|
= note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen
= help: if their presence wasn't intentional, you can remove them
help: if you want to keep them but make them visible in your source code, you can escape them
|
LL | println!("{:?}", '\u{202e}');
| ~~~~~~~~
```
|
|
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
| ^
```
|
|
```
error: bare CR not allowed in doc-comment
--> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32
|
LL | /// doc comment with bare CR: '␍'
| ^
```
|
|
Do not leave a `+ ` line with only whitespace. In reality, the user will want to remove the entire line.
|
|
```
3 | X0 Y0 Z0
| _____^ - -
| | _______| |
| || _________|
4 | ||| X1 Y1 Z1
5 | ||| X2 Y2 Z2
| |||____^__-__- `Z` label
| ||_____|__|
| |______| `Y` is a good letter too
| `X` is a good letter
```
|
|
When we have long code skips, we write `...` in the line number gutter.
For suggestions, we were "centering" the `...` with the line, but that was consistent with what we do in every other case.
|
|
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
|
|
Remove many `#[macro_use] extern crate foo` items
This requires the addition of more `use` items, which often make the code more verbose. But they also make the code easier to read, because `#[macro_use]` obscures where macros are defined.
r? `@fee1-dead`
|
|
|
|
tests: remove some trailing ws
Cleans one more case of trailing whitespace in tests.
|
|
|
|
|
|
|
|
r=davidtwco
conditionally ignore fatal diagnostic in the SilentEmitter
This change is primarily meant to allow rustfmt to ignore all diagnostics when using the `SilentEmitter`. Back in #121301 the `SilentEmitter` was shared between rustc and rustfmt. This changed rustfmt's behavior from ignoring all diagnostic to emitting fatal diagnostics, which lead to https://github.com/rust-lang/rustfmt/issues/6109.
These changes allow rustfmt to maintain its previous behaviour when using the `SilentEmitter`, while allowing rustc code to still emit fatal diagnostics.
|
|
This change is primarily meant to allow rustfmt to ignore all
diagnostics when using the `SilentEmitter`. Back in PR 121301 the
`SilentEmitter` was shared between rustc and rustfmt. This changed
rustfmt's behavior from ignoring all diagnostic to emitting fatal
diagnostics.
These changes allow rustfmt to maintain it's previous behaviour when
using the SilentEmitter, while allowing rustc code to still emit fatal
diagnostics.
|
|
```
error[E0308]: `match` arms have incompatible types
--> tests/ui/codemap_tests/huge_multispan_highlight.rs:98:18
|
6 | let _ = match true {
| ---------- `match` arms have incompatible types
7 | true => (
| _________________-
8 | | // last line shown in multispan header
... |
96 | |
97 | | ),
| |_________- this is found to be of type `()`
98 | false => "
| __________________^
... |
119 | |
120 | | ",
| |_________^ expected `()`, found `&str`
error[E0308]: `match` arms have incompatible types
--> tests/ui/codemap_tests/huge_multispan_highlight.rs:215:18
|
122 | let _ = match true {
| ---------- `match` arms have incompatible types
123 | true => (
| _________________-
124 | |
125 | | 1 // last line shown in multispan header
... |
213 | |
214 | | ),
| |_________- this is found to be of type `{integer}`
215 | false => "
| __________________^
216 | |
217 | |
218 | | 1 last line shown in multispan
... |
237 | |
238 | | ",
| |_________^ expected integer, found `&str`
```
|
|
r=oli-obk
Document `TRACK_DIAGNOSTIC` calls.
r? ```````@cjgillot```````
|
|
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
This match is complex enough that it's a good idea to enumerate every
variant.
This also means `can_be_top_or_sub` can just be `can_be_subdiag`.
|
|
Use `derive(Setters)` to derive setters, and then change
`JsonEmitter::new` to only have the arguments that are always used.
|
|
Because `HumanEmitter::new` is enough, in conjunction with the (renamed)
`stderr_destination` function.
|
|
And likewise with `ColorConfig::suggests_using_colors`. They both have a
single call site. And note that `BufWriter::supports_color()` always
returns false, which enables a small bit of constant folding along the
way.
|
|
They have the same signature, and the former just calls the latter.
|
|
|
|
|
|
|
|
Much better!
Note that this involves renaming (and updating the value of)
`DIAGNOSTIC_BUILDER` in clippy.
|
|
Note the change of the `D` to `d`, to match all the other names that
have `Subdiag` in them, such as `SubdiagnosticMessage` and
`derive(Subdiagnostic)`.
|
|
I started by changing it to `DiagData`, but that didn't feel right.
`DiagInner` felt much better.
|
