summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser/stmt.rs
AgeCommit message (Collapse)AuthorLines
2020-12-19implement edition-specific :pat behavior for 2015/18mark-2/+2
2020-11-26Only eat semicolons for statements that need themAaron Hill-2/+1
When parsing a statement (e.g. inside a function body), we now consider `struct Foo {};` and `$stmt;` to each consist of two statements: `struct Foo {}` and `;`, and `$stmt` and `;`. As a result, an attribute macro invoke as `fn foo() { #[attr] struct Bar{}; }` will see `struct Bar{}` as its input. Additionally, the 'unused semicolon' lint now fires in more places.
2020-11-26Properly handle attributes on statementsAaron Hill-38/+83
We now collect tokens for the underlying node wrapped by `StmtKind` instead of storing tokens directly in `Stmt`. `LazyTokenStream` now supports capturing a trailing semicolon after it is initially constructed. This allows us to avoid refactoring statement parsing to wrap the parsing of the semicolon in `parse_tokens`. Attributes on item statements (e.g. `fn foo() { #[bar] struct MyStruct; }`) are now treated as item attributes, not statement attributes, which is consistent with how we handle attributes on other kinds of statements. The feature-gating code is adjusted so that proc-macro attributes are still allowed on item statements on stable. Two built-in macros (`#[global_allocator]` and `#[test]`) needed to be adjusted to support being passed `Annotatable::Stmt`.
2020-10-07Detect blocks that could be struct expr bodiesEsteban Küber-9/+27
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.
2020-09-15Auto merge of #76171 - estebank:turbofish-the-revenge, r=davidtwcobors-6/+20
Detect turbofish with multiple type params missing leading `::` Fix #76072.
2020-09-14Detect turbofish with multiple type params missing leading `::`Esteban Küber-6/+20
Fix #76072.
2020-09-10Attach tokens to `ast::Stmt`Aaron Hill-1/+1
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.
2020-09-10Attach `TokenStream` to `ast::Block`Aaron Hill-1/+1
A `Block` does not have outer attributes, so we only capture tokens when parsing a `macro_rules!` matcher
2020-09-01Rollup merge of #76132 - Aaron1011:mac-call-stmt, r=petrochenkovTyler Mandry-2/+2
Factor out StmtKind::MacCall fields into `MacCallStmt` struct In PR #76130, I add a fourth field, which makes using a tuple variant somewhat unwieldy.
2020-08-30Factor out StmtKind::MacCall fields into `MacCallStmt` structAaron Hill-2/+2
In PR #76130, I add a fourth field, which makes using a tuple variant somewhat unwieldy.
2020-08-30parser: restore some fn visibility for rustfmtCaleb Cartwright-1/+2
2020-08-30mv compiler to compiler/mark-0/+427