| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Because 0.2.10 added supports for `ThinVec::splice`, and 0.2.12 is the
latest release.
|
|
r=tmiasko
Use restricted Damerau-Levenshtein distance for diagnostics
This replaces the existing Levenshtein algorithm with the Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change (a transposition) instead of two (a deletion and insertion). More specifically, this is a _restricted_ implementation, in that "ca" to "abc" cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the middle of a transposition. I believe that errors like that are sufficiently rare that it's not worth taking into account.
This was first brought up [on IRLO](https://internals.rust-lang.org/t/18227) when it was noticed that the diagnostic for `prinltn!` (transposed L and T) was `print!` and not `println!`. Only a single existing UI test was effected, with the result being an objective improvement.
~~I have left the method name and various other references to the Levenshtein algorithm untouched, as the exact manner in which the edit distance is calculated should not be relevant to the caller.~~
r? ``@estebank``
``@rustbot`` label +A-diagnostics +C-enhancement
|
|
|
|
|
|
Don't recover lifetimes/labels containing emojis as character literals
Fixes #108019.
Note that at the time of this commit, `unic-emoji-char` seems to have data tables only up to Unicode 5.0, but Unicode is already newer than this.
A newer emoji such as `🥺` will not be recognized as an emoji but older emojis such as `🐱` will.
This PR leaves a couple of FIXMEs where `unic_emoji_char::is_emoji` is used.
|
|
|
|
|
|
Suggest fix for misplaced generic params on fn item #103366
fixes #103366
This still has some work to go, but works for 2/3 of the initial base cases described in #1033366
simple fn:
```
error: expected identifier, found `<`
--> shreys/test_1.rs:1:3
|
1 | fn<T> id(x: T) -> T { x }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn id<T>(x: T) -> T { x }
| ~~~~
```
Complicated bounds
```
error: expected identifier, found `<`
--> spanishpear/test_2.rs:1:3
|
1 | fn<'a, B: 'a + std::ops::Add<Output = u32>> f(_x: B) { }
| ^ expected identifier
|
help: help: place the generic parameter list after the function name:
|
1 | fn f<'a, B: 'a + std::ops::Add<Output = u32>>(_x: B) { }
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Opening a draft PR for comments on approach, particularly I have the following questions:
- [x] Is it okay to be using `err.span_suggestion` over struct derives? I struggled to get the initial implementation (particularly the correct suggestion message) on struct derives, although I think given what I've learned since starting, I could attempt re-doing it with that approach.
- [x] in the case where the snippet cannot be obtained from a span, is the `help` but no suggestion okay? I think yes (also, when does this case occur?)
- [x] are there any red flags for the generalisation of this work for relevant item kinds (i.e. `struct`, `enum`, `trait`, and `union`). My basic testing indicates it does work for those types except the help tip is currently hardcoded to `after the function name` - which should change dependent on the item.
- [x] I am planning to not show the suggestion if there is already a `<` after the item identifier, (i.e. if there are already generics, as after a function name per the original issue). Any major objections?
- [x] Is the style of error okay? I wasn't sure if there was a way to make it display nicer, or if thats handled by span_suggestion
These aren't blocking questions, and I will keep working on:
- check if there is a `<` after the ident (and if so, not showing the suggestion)
- generalize the help message
- figuring out how to write/run/etc ui tests (including reading the docs for them)
- logic cleanups
|
|
Note that at the time of this commit, `unic-emoji-char` seems to have
data tables only up to Unicode 5.0, but Unicode is already newer than
this.
A newer emoji such as `🥺` will not be recognized as an emoji
but older emojis such as `🐱` will.
|
|
Migrate some of `rustc_parse` to derive diagnostics
`@rustbot` label +A-translation
r? rust-lang/diagnostics
cc #100717
|
|
|
|
|
|
lenko-d:default_value_for_a_lifetime_generic_parameter_produces_confusing_diagnostic, r=compiler-errors
Recover from lifetimes with default lifetimes in generic args
Fixes [#107492](https://github.com/rust-lang/rust/issues/107492)
|
|
|
|
|
|
|
|
Replace `ConstFnMutClosure` with const closures
Also fixes a parser bug. cc `@oli-obk` for compiler changes
|
|
Improve `TokenCursor`.
Some small improvements, for things that were bugging me.
Best reviewed one commit at a time.
r? ``@petrochenkov``
|
|
Parse and recover from type ascription in patterns
Reintroduce part of #106960, which was reverted in #107478.
r? `@compiler-errors`
|
|
This makes it clear they return token trees, and makes for a nice
comparison against `TokenCursor` which returns tokens.
|
|
The motivation here is to eliminate the `Option<(Delimiter,
DelimSpan)>`, which is `None` for the outermost token stream and `Some`
for all other token streams.
We are already treating the innermost frame specially -- this is the
`frame` vs `stack` distinction in `TokenCursor`. We can push that
further so that `frame` only contains the cursor, and `stack` elements
contain the delimiters for their children. When we are in the outermost
token stream `stack` is empty, so there are no stored delimiters, which
is what we want because the outermost token stream *has* no delimiters.
This change also shrinks `TokenCursor`, which shrinks `Parser` and
`LazyAttrTokenStreamImpl`, which is nice.
|
|
|
|
Sometimes the parser needs to desugar a doc comment into `#[doc =
r"foo"]`. Currently it does this in a hacky way: by pushing a "fake" new
frame (one without a delimiter) onto the `TokenCursor` stack.
This commit changes things so that the token stream itself is modified
in place. The nice thing about this is that it means
`TokenCursorFrame::delim_sp` is now only `None` for the outermost frame.
|
|
|
|
Rename `rust_2015` → `is_rust_2015`
r? ```@compiler-errors```
https://github.com/rust-lang/rust/pull/107508#discussion_r1092300088
|
|
Improve diagnostic for missing space in range pattern
Improves the diagnostic in #107425 by turning it into a note explaining the parsing issue.
r? `@compiler-errors`
|
|
r=jackh726
Recover `_` as `..` in field pattern
|
|
|
|
|
|
|
|
|
|
commits
Revert "review comment: Remove AST AnonTy"
This reverts commit 020cca8d36cb678e3ddc2ead41364be314d19e93.
Revert "Ensure macros are not affected"
This reverts commit 12d18e403139eeeeb339e8611b2bed4910864edb.
Revert "Emit fewer errors on patterns with possible type ascription"
This reverts commit c847a01a3b1f620c4fdb98c75805033e768975d1.
Revert "Teach parser to understand fake anonymous enum syntax"
This reverts commit 2d824206655bfb26cb5eed43490ee396542b153e.
|
|
|
|
#[derive(Subdiagnostic)] does not allow multiple subdiagnostics on one
variant, as in NonItemInItemListSub::Other.
|
|
|
|
This is required in order to support translatable diagnostics.
|
|
|
|
The check previously matched this, and suggested adding a missing
`struct`:
pub Foo(...):
It was probably intended to match this instead (semicolon instead of
colon):
pub Foo(...);
|
|
|
|
|
|
|
|
|
|
Make the "extra if in let...else block" hint a suggestion
Changes the hint to a suggestion, suggested in #107213.
r? ```@estebank```
|
|
Improve enum checks
Some light refactoring.
|
|
|
|
Fix invalid float literal suggestions when recovering an integer
Only suggest adding a zero to integers with a preceding dot when the change will result in a valid floating point literal.
For example, `.0x0` should not be turned into `0.0x0`.
r? nnethercote
|
|
|
|
Only suggest adding a zero to integers with a preceding dot when the change will
result in a valid floating point literal.
For example, `.0x0` should not be turned into `0.0x0`.
|
|
|
