| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use correct line offsets for doctests
Not yet tested.
This doesn't handle char positions. It could if I collected a map of char offsets and lines, but this is a bit more work and requires hooking into the parser much more (unsure if it's possible).
r? @QuietMisdreavus
(fixes #45868)
|
|
|
|
|
|
|
|
When external tools like `rustfmt` calls to `reset_err_count` for handler
reusing, it will set the error count on the handler to 0, but since
https://github.com/rust-lang/rust/pull/47146 the handler will contain
status that will prevent the error count to be bumped if this handler is
reused.
This caused `rustfmt` idempotency tests to fail:
https://github.com/rust-lang-nursery/rustfmt/issues/2338
Fixes: https://github.com/rust-lang-nursery/rustfmt/issues/2338
|
|
This ensures that if we emit the same diagnostic twice, the error count will
match the real number of errors shown to the user.
Fixes #42106
|
|
|
|
|
|
|
|
Use spans for -Z external-macro-backtrace
```
% rustc ui/type-check/cannot_infer_local_or_vec.rs -Z external-macro-backtrace
error[E0282]: type annotations needed
--> <vec macros>:3:1
|
1 | / ( $ elem : expr ; $ n : expr ) => (
2 | | $ crate :: vec :: from_elem ( $ elem , $ n ) ) ; ( $ ( $ x : expr ) , * ) => (
3 | | < [ _ ] > :: into_vec ( box [ $ ( $ x ) , * ] ) ) ; ( $ ( $ x : expr , ) * )
| | ^^^^^^^^^^^^^^^^^^^^^
| | |
| | cannot infer type for `T`
4 | | => ( vec ! [ $ ( $ x ) , * ] )
| |______________________________- in this expansion of `vec!`
|
::: ui/type-check/cannot_infer_local_or_vec.rs
|
12 | let x = vec![];
| - ------ in this macro invocation
| |
| consider giving `x` a type
error: aborting due to previous error
```
|
|
|
|
```
% rustc ui/type-check/cannot_infer_local_or_vec.rs -Z external-macro-backtrace
error[E0282]: type annotations needed
--> <vec macros>:3:1
|
1 | / ( $ elem : expr ; $ n : expr ) => (
2 | | $ crate :: vec :: from_elem ( $ elem , $ n ) ) ; ( $ ( $ x : expr ) , * ) => (
3 | | < [ _ ] > :: into_vec ( box [ $ ( $ x ) , * ] ) ) ; ( $ ( $ x : expr , ) * )
| | ^^^^^^^^^^^^^^^^^^^^^
| | |
| | cannot infer type for `T`
4 | | => ( vec ! [ $ ( $ x ) , * ] )
| |______________________________- in this expansion of `vec!`
|
::: ui/type-check/cannot_infer_local_or_vec.rs
|
12 | let x = vec![];
| - ------ in this macro invocation
| |
| consider giving `x` a type
error: aborting due to previous error
```
|
|
Display `\t` in diagnostics code as four spaces
Follow up to #44386 using the unicode variable width machinery from #45711 to replace tabs in the source code when displaying a diagnostic error with four spaces (instead of only one), while properly accounting for this when calculating underlines.
Partly addresses #44618.
|
|
Account for missing keyword in fn/struct definition
Fix #38911.
|
|
|
|
|
|
|
|
Include rendered diagnostic in json
r? @petrochenkov
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Refactor internal suggestion API
~~The only functional change is that whitespace, which is suggested to be added, also gets `^^^^` under it. An example is shown in the tests (the only test that changed).~~
Continuation of #41876
r? @nagisa
the changes are probably best viewed [without whitespace](https://github.com/rust-lang/rust/pull/45741/files?w=1)
|
|
|
|
Display spans correctly when there are zero-width or wide characters
Hopefully...
* fixes #45211
* fixes #8706
---
Before:
```
error: invalid width `7` for integer literal
--> unicode_2.rs:12:25
|
12 | let _ = ("a̐éö̲", 0u7);
| ^^^
|
= help: valid widths are 8, 16, 32, 64 and 128
error: invalid width `42` for integer literal
--> unicode_2.rs:13:20
|
13 | let _ = ("아あ", 1i42);
| ^^^^
|
= help: valid widths are 8, 16, 32, 64 and 128
error: aborting due to 2 previous errors
```
After:
```
error: invalid width `7` for integer literal
--> unicode_2.rs:12:25
|
12 | let _ = ("a̐éö̲", 0u7);
| ^^^
|
= help: valid widths are 8, 16, 32, 64 and 128
error: invalid width `42` for integer literal
--> unicode_2.rs:13:20
|
13 | let _ = ("아あ", 1i42);
| ^^^^
|
= help: valid widths are 8, 16, 32, 64 and 128
error: aborting due to 2 previous errors
```
Spans might display incorrectly on the browser.
r? @estebank
|
|
|
|
|
|
|
|
|
|
Don't emit the same compiler diagnostic twice.
This PR makes the compiler filter out diagnostic messages that have already been emitted during the same compilation session.
|
|
Add short error message-format
Fixes #42653.
|
|
|
|
|
|
|
|
`CodeSuggestion` doesn't live in the `diagnostic` module.
|
|
Fixes #38384
Most of the Rust community uses 4 spaces for indentation,
but there are also tab users of Rust (including myself!).
This patch fixes a bug in error printing which mispositions
error indicators when near code with tabs.
The code attempted to fix the issue by replacing spaces
with tabs, but it sadly wasn't enough, as sometimes
you may not print spaces but _ or ^ instead.
This patch employs the reverse strategy: it replaces each
tab with a space, so that the number of _ and ^ and spaces
in error indicators below the code snippet line up
perfectly.
In a study [1] preceeding this patch, we could see that
this strategy is also chosen by gcc version 6.3.0.
Its not perfect, as the output is not beautiful, but its
the easiest to implement. If anyone wants to improve on
this, be my guest! This patch is meant as improvement of
the status quo, not as perfect end status. It fixes the
actual issue of mispositioning error indicators.
[1]: https://github.com/rust-lang/rust/issues/38384#issuecomment-326813710
|
|
Initial diagnostic API for proc-macros.
This commit introduces the ability to create and emit `Diagnostic` structures from proc-macros, allowing for proc-macro authors to emit warning, error, note, and help messages just like the compiler does.
The API is somewhat based on the diagnostic API already present in `rustc` with several changes that improve usability. The entry point into the diagnostic API is a new `Diagnostic` type which is primarily created through new `error`, `warning`, `help`, and `note` methods on `Span`. The `Diagnostic` type records the diagnostic level, message, and optional `Span` for the top-level diagnostic and contains a `Vec` of all of the child diagnostics. Child diagnostics can be added through builder methods on `Diagnostic`.
A typical use of the API may look like:
```rust
let token = parse_token();
let val = parse_val();
val.span
.error(format!("expected A but found {}", val))
.span_note(token.span, "because of this token")
.help("consider using a different token")
.emit();
```
cc @jseyfried @nrc @dtolnay @alexcrichton
|
|
Make fields of `Span` private
I actually tried to intern spans and benchmark the result<sup>*</sup>, and this was a prerequisite.
This kind of encapsulation will be a prerequisite for any other attempt to compress span's representation, so I decided to submit this change alone.
The issue https://github.com/rust-lang/rust/issues/43088 seems relevant, but it looks like `SpanId` won't be able to reuse this interface, unless the tables are global (like interner that I tried) and are not a part of HIR.
r? @michaelwoerister anyway
<sup>*</sup> Interning means 2-3 times more space is required for a single span, but duplicates are free. In practice it turned out that duplicates are not *that* common, so more memory was wasted by interning rather than saved.
|
|
|
|
Add reset_err_count() to errors::Handler
The motivation here is to allow rustfmt to recover from parse errors after failing to parse macros (cc https://github.com/rust-lang-nursery/rustfmt/issues/1742).
r? @nrc
|
|
This commit introduces the ability to create and emit `Diagnostic`
structures from proc-macros, allowing for proc-macro authors to emit
warning, error, note, and help messages just like the compiler does.
|
|
|
|
Fix a byte/char confusion issue in the error emitter
Fixes #44078. Fixes #44023.
The start_col member is given in chars, while the code previously assumed it was given in bytes.
The more basic issue #44080 doesn't get fixed.
|
|
rustc: Start moving toward "try_get is a bug" for incremental
This PR is an effort to burn down some of the work items on #42633. The basic change here was to leave the `try_get` function exposed but have it return a `DiagnosticBuilder` instead of a `CycleError`. This means that it should be a compiler bug to *not* handle the error as dropping a diagnostic should result in a complier panic.
After that change it was then necessary to update the compiler's callsites of `try_get` to handle the error coming out. These were handled as:
* The `sized_constraint` and `needs_drop_raw` checks take the diagnostic and defer it as a compiler bug. This was a new piece of functionality added to the error handling infrastructure, and the idea is that for both these checks a "real" compiler error should be emitted elsewhere, so it's only a bug if we don't actually emit the complier error elsewhere.
* MIR inlining was updated to just ignore the diagnostic. This is being tracked by https://github.com/rust-lang/rust/issues/43542 which sounded like it either already had some work underway or was planning to change regardless.
* The final case, `item_path`, is still sort of up for debate. At the time of this writing this PR simply removes the invocations of `try_get` there, assuming that the query will always succeed. This turns out to be true for the test suite anyway! It sounds like, though, that this logic was intended to assist in "weird" situations like `RUST_LOG` where debug implementations can trigger at any time. This PR would therefore, however, break those implementations.
I'm unfortunately sort of out of ideas on how to handle `item_path`, but other thoughts would be welcome!
Closes #42633
|
|
This adds a function to `DiagnosticBuilder` to delay the entire diagnostic as a
bug to be emitted at a later time. This'll end up getting used in the compiler
in the subsequent commits...
|
|
*: remove crate_{name,type} attributes
Fixes #41701.
r? @arielb1
|
|
Fixes #41701.
|
|
Fixes #44078. Fixes #44023.
The start_col member is given in chars,
while the code previously assumed it was given in bytes.
The more basic issue #44080 doesn't get fixed.
|
