| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
Modify message for keyword as identifier name
This is a temporary solution to #46311.
The message is generic enough to cover both cases and is probably a fine enough solution to the specific problem described in the task. However, the underlying reason for this to be wrong is that `next_token_inner` returns `Lifetime` even if the token is a label. That's not simple, as the syntax for both can be quite similar and it may need to take a look to the next token to make a decision. I'm not sure I have enough knowledge about the project to be able to solve that (yet!), so I thought I'll fix the immediate problem first.
|
|
|
|
Rename C-like enum to Field-less enum
There is no need to reference the C programming language to explain this concept.
|
|
|
|
Point to next token when it is in the expected line
r? @nikomatsakis
|
|
Fix hygiene bug.
Fixes #42708.
r? @nrc
|
|
Generic Associated Types Parsing & Name Resolution
Hi!
This PR adds parsing for generic associated types! :tada: :tada: :tada:
Tracking Issue: #44265
## Notes For Reviewers
* [x] I still need to add the stdout and stderr files to my ui tests. It takes me a *long* time to compile the compiler locally, so I'm going to add this as soon as possible in the next day or so.
* [ ] My current ui tests aren't very good or very thorough. I'm reusing the `parse_generics` and `parse_where_clause` methods from elsewhere in the parser, so my changes work without being particularly complex. I'm not sure if I should duplicate all of the generics test cases for generic associated types. It might actually be appropriate to duplicate everything here, since we don't want to rely on an implementation detail in case it changes in the future. If you think so too, I'll adapt all of the generics test cases into the generic associated types test cases.
* [ ] There is still more work required to make the run-pass tests pass here. In particular, we need to make the following errors disappear:
```
error[E0110]: lifetime parameters are not allowed on this type
--> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:23:41
|
23 | bar: <T as StreamingIterator>::Item<'static>,
| ^^^^^^^ lifetime parameter not allowed on this type
```
```
error[E0261]: use of undeclared lifetime name `'a`
--> ./src/test/run-pass/rfc1598-generic-associated-types/iterable.rs:15:47
|
15 | type Iter<'a>: Iterator<Item = Self::Item<'a>>;
| ^^ undeclared lifetime
```
There is a FIXME comment in streaming_iterator. If you uncomment that line, you get the following:
```
error: expected one of `!`, `+`, `,`, `::`, or `>`, found `=`
--> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:29:45
|
29 | fn foo<T: for<'a> StreamingIterator<Item<'a>=&'a [i32]>>(iter: T) { /* ... */ }
| ^ expected one of `!`, `+`, `,`, `::`, or `>` here
```
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
Account for missing keyword in fn/struct definition
Fix #38911.
|
|
This commit adds support for nested groups inside `use` declarations,
such as `use foo::{bar, sub::{baz::Foo, *}};`.
|
|
|
|
|
|
|
|
|
|
Added note that specifies a semicolon should be removed after a given struct
|
|
|
|
|
|
|
|
|
|
Try to identify the following code in order to provide better
diagnostics, but return the error to bail out early during the parse.
|
|
When encountering `pub ident`, attempt to identify the code that comes
afterwards, wether it is a brace block (assume it is a struct), a paren
list followed by a colon (assume struct) or a paren list followed by a
block (assume a fn). Consume those blocks to avoid any further parser
errors and return a `Placeholder` item in order to allow the parser to
continue. In the case of unenclosed blocks, the behavior is the same as
it is currently: no further errors are processed.
|
|
|
|
|
|
Support `::crate` in paths
cc https://github.com/rust-lang/rust/issues/45477
Fixes https://github.com/rust-lang/rust/issues/45229
|
|
|
|
|
|
|
|
Remove some outdated messages from "no patterns allowed" errors
|
|
Add error for `...` in expressions
Follow-up to https://github.com/rust-lang/rust/pull/44709
Tracking issue: https://github.com/rust-lang/rust/issues/28237
* Using `...` in expressions was a warning, now it's an error
* The error message suggests using `..` or `..=` instead, and explains the difference
* Updated remaining occurrences of `...` to `..=`
r? petrochenkov
|
|
Detect `=` -> `:` typo in let bindings
When encountering a let binding type error, attempt to parse as
initializer instead. If successful, it is likely just a typo:
```rust
fn main() {
let x: Vec::with_capacity(10);
}
```
```
error: expected type, found `10`
--> file.rs:3:31
|
3 | let x: Vec::with_capacity(10, 20);
| -- ^^
| ||
| |help: did you mean assign here?: `=`
| while parsing the type for `x`
```
Fix #43703.
|
|
|
|
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
|
|
Add a nicer error message for missing in for loop, fixes #40782.
As suggested by @estebank in issue #40782, this works in the same way as #42578: if the in keyword is missing, we continue parsing the expression and if this works correctly an adapted error message is produced. Otherwise we return the old error.
A specific test case has also been added.
This is my first PR on rust-lang/rust so any feedback is very welcome.
|
|
When encountering a let binding type error, attempt to parse as
initializer instead. If successful, it is likely just a typo:
```rust
fn main() {
let x: Vec::with_capacity(10);
}
```
```
error: expected type, found `10`
--> file.rs:3:31
|
3 | let x: Vec::with_capacity(10, 20);
| -- ^^
| ||
| |help: did you mean assign here?: `=`
| while parsing the type for `x`
```
|
|
This moves the well formedness checks to the AST validation pass. Tests
were adjusted.
The auto keyword should be back-compat now.
|
|
Now we can do the well formedness checks in the parser, yay!
|
|
Adds an `IsAuto` field to `ItemTrait` which flags if the trait was
declared as an `auto trait`.
Auto traits cannot have generics nor super traits.
|
|
DefaultImpl is a highly confusing name for what we now call auto impls,
as in `impl Send for ..`. The name auto impl is not formally decided
but for sanity anything is better than `DefaultImpl` which refers
neither to `default impl` nor to `impl Default`.
|
|
|
|
|
|
|
|
|
|
|
