| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
rustc_parse: fix spans on cast and range exprs with attrs
Currently the span for cast and range expressions does not include the span of attributes associated to the lhs which is causing some issues for us in rustfmt.
```rust
fn foo() -> i64 {
#[attr]
1u64 as i64
}
fn bar() -> Range<i32> {
#[attr]
1..2
}
```
This corrects the span for cast and range expressions to fully include the span of child nodes
|
|
|
|
|
|
|
|
|
|
This approach lives exclusively in the parser, so struct expr bodies
that are syntactically correct on their own but are otherwise incorrect
will still emit confusing errors, like in the following case:
```rust
fn foo() -> Foo {
bar: Vec::new()
}
```
```
error[E0425]: cannot find value `bar` in this scope
--> src/file.rs:5:5
|
5 | bar: Vec::new()
| ^^^ expecting a type here because of type ascription
error[E0214]: parenthesized type parameters may only be used with a `Fn` trait
--> src/file.rs:5:15
|
5 | bar: Vec::new()
| ^^^^^ only `Fn` traits may use parentheses
error[E0107]: wrong number of type arguments: expected 1, found 0
--> src/file.rs:5:10
|
5 | bar: Vec::new()
| ^^^^^^^^^^ expected 1 type argument
```
If that field had a trailing comma, that would be a parse error and it
would trigger the new, more targetted, error:
```
error: struct literal body without path
--> file.rs:4:17
|
4 | fn foo() -> Foo {
| _________________^
5 | | bar: Vec::new(),
6 | | }
| |_^
|
help: you might have forgotten to add the struct literal inside the block
|
4 | fn foo() -> Foo { Path {
5 | bar: Vec::new(),
6 | } }
|
```
Partially address last part of #34255.
|
|
|
|
|
|
|
|
|
|
Detect turbofish with multiple type params missing leading `::`
Fix #76072.
|
|
Fix #76072.
|
|
case
|
|
We currently only attach tokens when parsing a `:stmt` matcher for a
`macro_rules!` macro. Proc-macro attributes on statements are still
unstable, and need additional work.
|
|
A `Visibility` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
|
|
|
|
An `AttrItem` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
|
|
An `NtLiteral` just wraps an `Expr`, so we don't need to add a new `tokens`
field to an AST struct.
|
|
A `Ty` does not have outer attributes, so we only capture tokens
when parsing a `macro_rules!` matcher
|
|
A `Block` does not have outer attributes, so we only capture tokens when
parsing a `macro_rules!` matcher
|
|
|
|
To match better naming from proc-macro
|
|
Improve recovery on malformed format call
The token following a format expression should be a comma. However, when it is replaced with a similar token (such as a dot), then the corresponding error is emitted, but the token is treated as a comma, and the parsing step continues.
r? @petrochenkov
|
|
If a comma in a format call is replaced with a similar token, then we
emit an error and continue parsing, instead of stopping at this point.
|
|
Factor out StmtKind::MacCall fields into `MacCallStmt` struct
In PR #76130, I add a fourth field, which makes using a tuple variant
somewhat unwieldy.
|
|
Restore public visibility on some parsing functions for rustfmt
In #74826 the visibility of several parsing functions was reduced. However, rustfmt is an external consumer of some of these functions as well and needs the visibility to be public, similar to other elements in rustc_parse such as `parse_ident`
https://github.com/rust-lang/rust/blob/db534b3ac286cf45688c3bbae6aa6e77439e52d2/src/librustc_parse/parser/mod.rs#L433-L436
|
|
In PR #76130, I add a fourth field, which makes using a tuple variant
somewhat unwieldy.
|
|
Previous implementation used the `Parser::parse_expr` function in order
to extract the format expression. If the first comma following the
format expression was mistakenly replaced with a dot, then the next
format expression was eaten by the function, because it looked as a
syntactically valid expression, which resulted in incorrectly spanned
error messages.
The way the format expression is exctracted is changed: we first look at
the first available token in the first argument supplied to the
`format!` macro call. If it is a string literal, then it is promoted as
a format expression immediatly, otherwise we fall back to the original
`parse_expr`-related method.
This allows us to ensure that the parser won't consume too much tokens
when a typo is made.
A test has been created so that it is ensured that the issue is properly
fixed.
|
|
|
|
|
