| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
libsyntax/parse: fix missing kind error reporting
Fixes #41161.
Fixes #41239.
|
|
Fixes #41161.
Fixes #41239.
|
|
Use proper span for tuple index parsed as float
Fix diagnostic suggestion from:
```rust
help: try parenthesizing the first index
| (1, (2, 3)).((1, (2, 3)).1).1;
```
to the correct:
```rust
help: try parenthesizing the first index
| ((1, (2, 3)).1).1;
```
Fix #41081.
|
|
Fix diagnostic suggestion from:
```rust
help: try parenthesizing the first index
| (1, (2, 3)).((1, (2, 3)).1).1;
```
to the correct:
```rust
help: try parenthesizing the first index
| ((1, (2, 3)).1).1;
```
|
|
|
|
Fixes #40149
|
|
* Point at where the token was expected instead of the last token
successfuly parsed.
* Only show `unexpected token` if the next char and the unexpected token
don't have the same span.
* Change some cfail and pfail tests to ui test.
* Don't show all possible tokens in span label if they are more than 6.
|
|
```rust
error: expected one of `.`, `;`, `?`, `}`, or an operator, found `)`
--> $DIR/token-error-correct-3.rs:29:9
|
25 | foo()
| - expected one of `.`, `;`, `?`, `}`, or an operator after this
...
29 | } else {
| ^ unexpected token
```
|
|
|
|
|
|
|
|
`tokenstream::TokenTree::Sequence`.
|
|
|
|
Closes #37340.
|
|
|
|
parser: use suggestions instead of helps with code in them
|
|
|
|
This is the first part of #39018. One of the common things for new users
coming from more dynamic languages like JavaScript, Python or Ruby is to
use `+` to concatenate strings. However, this doesn't work that way in
Rust unless the first type is a `String`. This commit adds a check for
this use case and outputs a new error as well as a suggestion to guide
the user towards the desired behavior. It also adds a new test case to
test the output of the error.
|
|
Bounds parsing refactoring 2
See https://github.com/rust-lang/rust/pull/37511 for previous discussion.
cc @matklad
Relaxed parsing rules:
- zero bounds after `:` are allowed in all contexts.
- zero predicates are allowed after `where`.
- trailing separator `,` is allowed after predicates in `where` clauses not followed by `{`.
Other parsing rules:
- trailing separator `+` is still allowed in all bound lists.
Code is also cleaned up and tests added.
I haven't touched parsing of trait object types yet, I'll do it later.
|
|
exclusive range patterns
adds `..` patterns to the language under a feature gate (`exclusive_range_pattern`).
This allows turning
``` rust
match i {
0...9 => {},
10...19 => {},
20...29 => {},
_ => {}
}
```
into
``` rust
match i {
0..10 => {},
10..20 => {},
20..30 => {},
_ => {}
}
```
|
|
|
|
|
|
|
|
|
|
Fix regression in parsing of trait object types
Fixes https://github.com/rust-lang/rust/issues/39169
Accepting parens in this position is a regression itself, introduced in Rust 1.6 by https://github.com/rust-lang/rust/pull/29870, so I hope to revert this in my next bounds refactoring patch (possibly with a warning, crater run, etc).
r? @eddyb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix syntax error in the compiler
Currently `rustc` accepts the following code: `fn f<'a>() where 'a {}`. This should be a syntax error, shouldn't it?
Not sure if my changes actually compile, waiting for the LLVM to build.
|
|
Don't allow lifetimes without any bounds at all
|
|
Don't spin expanding stmt macros.
If we can't make progress when parsing a macro expansion as a statement then we should just bail.
This alleviates the symptoms shown in e.g. #37113 and #37234 but it doesn't fix the problem that parsing invalid enum bodies (and others) leaves the parser in a crappy state.
I'm not sold on this strategy (checking `tokens_consumed`), so if anyone has a better idea, I'm all ears!
|
|
|
|
The new handling fixed a latent bug in the parser error handling where
it would only abort after the second error (when configured to stop
after the first error). This is because the check for `error_count != 0`
was occuring before the increment. Since the increment is tied to the
`emit()` call now this no longer occurs.
|
|
Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.
There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.
|
|
Recover out of an enum or struct's braced block.
If we encounter a syntax error inside of a braced block, then we should
fail by consuming the rest of the block if possible.
This implements such recovery for enums and structs.
Fixes #37113.
|
|
If we can't make progress when parsing a macro expansion as a statement
then we should just bail.
This alleviates the symptoms shown in e.g. #37113 but it doesn't fix the
problem that parsing invalid enum bodies (and others) leaves the parser
in a crappy state.
|
|
If we encounter a syntax error inside of a braced block, then we should
fail by consuming the rest of the block if possible.
This implements such recovery for enums and structs.
Fixes #37113.
|
|
|
|
|
|
|
|
|
|
|
|
Specific error message for missplaced doc comments
Identify when documetation comments have been missplaced in the following places:
* After a struct element:
```rust
// file.rs:
struct X {
a: u8 /** document a */,
}
```
```bash
$ rustc file.rs
file.rs:2:11: 2:28 error: found documentation comment that doesn't
document anything
file.rs:2 a: u8 /** document a */,
^~~~~~~~~~~~~~~~~
file.rs:2:11: 2:28 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
* As the last line of a struct:
```rust
// file.rs:
struct X {
a: u8,
/// incorrect documentation
}
```
```bash
$ rustc file.rs
file.rs:3:5: 3:27 error: found a documentation comment that doesn't
document anything
file.rs:3 /// incorrect documentation
^~~~~~~~~~~~~~~~~~~~~~
file.rs:3:5: 3:27 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
* As the last line of a `fn`:
```rust
// file.rs:
fn main() {
let x = 1;
/// incorrect documentation
}
```
```bash
$ rustc file.rs
file.rs:3:5: 3:27 error: found a documentation comment that doesn't
document anything
file.rs:3 /// incorrect documentation
^~~~~~~~~~~~~~~~~~~~~~
file.rs:3:5: 3:27 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
Fix #27429, #30322
|
|
|
