| Age | Commit message (Collapse) | Author | Lines |
|---|
|
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
|
|
|
|
Then use them through a query based on resolver outputs
|
|
If a symbol name can only be imported from one place for a type, and
as long as it was not glob-imported anywhere in the current crate, we
can trim its printed path and print only the name.
This has wide implications on error messages with types, for example,
shortening `std::vec::Vec` to just `Vec`, as long as there is no other
`Vec` importable anywhere.
This adds a new '-Z trim-diagnostic-paths=false' option to control this
feature.
On the good path, with no diagnosis printed, we should try to avoid
issuing this query, so we need to prevent trimmed_def_paths query on
several cases.
This change also relies on a previous commit that differentiates
between `Debug` and `Display` on various rustc types, where the latter
is trimmed and presented to the user and the former is not.
|
|
|
|
|
|
|
|
|
|
this also extracts macro item parsers.
|
|
|
|
|
|
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
|
|
https://github.com/rust-lang/rust/issues/60532
|
|
Account for paths in incorrect pub qualifier help
Handle case where incorrect pub qualifier with a mod path is used and provide the same help given for all other incorrect qualifiers by making the `pub(crate)` parse check more specific.
|
|
Added an explanation for the E0704 error.
# Description
Adds an explanation on the E0704 error. I tried to stick as closely to the message that the compiler generates. It's the first time I am fixing error messages here, so if there is something I did wrong or should improve, please let me know.
closes #55398
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
April 2016's Issue #33174 called out the E0446 diagnostics as
confusing. While adding the name of the restricted type to the message
(548e681f) clarified matters somewhat, Esteban Küber pointed out that we
could stand to place a secondary span on the restricted type.
Here, we differentiate between crate-visible, truly private, and
otherwise restricted types, and place a secondary span specifically on
the visibility modifier of the restricted type's declaration (which we
can do now that HIR visibilities have spans!).
At long last, this resolves #33174.
|
|
|
|
|
|
|
|
- Recover from struct parse error on match and point out missing match
body.
- Point at struct when finding non-identifier while parsing its fields.
- Add label to "expected identifier, found {}" error.
|
|
Account for missing keyword in fn/struct definition
Fix #38911.
|
|
Try to identify the following code in order to provide better
diagnostics, but return the error to bail out early during the parse.
|
|
|
|
This reverts commit 5558c64f33446225739c1153b43d2e309bb4f50e.
|
|
See #33525 for details.
|
|
|
|
|
|
|
|
Given the following statement
```rust
pub (a) fn afn() {}
```
Provide the following diagnostic:
```rust
error: incorrect restriction in `pub`
--> file.rs:15:1
|
15 | pub (a) fn afn() {}
| ^^^^^^^
|
= help: some valid visibility restrictions are:
`pub(crate)`: visible only on the current crate
`pub(super)`: visible only in the current module's parent
`pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
| pub (in a) fn afn() {}
```
Remove cruft from old `pub(path)` syntax.
|
