| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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.
|
|
This commit alters the `rustc::ty::maps` implementation to ensure that all
output diagnostics from the compiler are tracked for the duration of each query.
These are then intended to be replayed back the first time a cached value is
loaded, and otherwise the cache should operate the same as it does today.
Closes #42513
|
|
The motivation here is to allow rustfmt to recover from parse errors
after failing to parse macros.
|
|
rustc: Remove some dead code
Extracted from https://github.com/rust-lang/rust/pull/43192
r? @eddyb
|
|
Improve placement of `use` suggestions
r? @nrc
cc @estebank @Mark-Simulacrum
fixes #42835
fixes #42548
fixes #43769
|
|
|
|
|
|
Fix typos & us spellings
Fixing some typos and non en-US spellings.
(Update of PR https://github.com/rust-lang/rust/pull/42812 )
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
Point at `:` when using it instead of `;`
When triggering type ascription in such a way that we can infer a
statement end was intended, add a suggestion for the change. Always
point out the reason for the expectation of a type is due to type
ascription.
Fix #42057, #41928.
|
|
|
|
Now there's a way to add suggestions that hide the suggested code when
presented inline, to avoid weird wording when short code snippets are
added at the end.
|
|
|
|
|
|
|
|
|
|
When there're more than one suggestions in the same diagnostic, they are
displayed in their own block, instead of inline. In order to reduce
confusion, those blocks now display the line number.
|
|
This reverts commit 5558c64f33446225739c1153b43d2e309bb4f50e.
|
|
|
|
|
|
Implement lazy loading of external crates' sources. Fixes #38875
Fixes #38875. This is a follow-up to #42507. When a (now correctly translated) span from an external crate is referenced in a error, warning or info message, we still don't have the source code being referenced.
Since stuffing the source in the serialized metadata of an rlib is extremely wasteful, the following scheme has been implemented:
* File maps now contain a source hash that gets serialized as well.
* When a span is rendered in a message, the source hash in the corresponding file map(s) is used to try and load the source from the corresponding file on disk. If the file is not found or the hashes don't match, the failed attempt is recorded (and not retried).
* The machinery fetching source lines from file maps is augmented to use the lazily loaded external source as a secondary fallback for file maps belonging to external crates.
This required a small change to the expected stderr of one UI test (it now renders a span, where previously was none).
Further work can be done based on this - some of the machinery previously used to hide external spans is possibly obsolete and the hashing code can be reused in different places as well.
r? @eddyb
|
|
Rollup of 5 pull requests
- Successful merges: #42616, #42651, #42654, #42656, #42685
- Failed merges:
|
