about summary refs log tree commit diff
path: root/compiler/rustc_parse/src
AgeCommit message (Collapse)AuthorLines
2020-11-11Implement destructuring assignment for structs and slicesFabian Zaiser-2/+8
Co-authored-by: varkor <github@varkor.com>
2020-11-09Rollup merge of #78710 - petrochenkov:macvisit, r=davidtwcoDylan DPC-5/+1
rustc_ast: Do not panic by default when visiting macro calls Panicking by default made sense when we didn't have HIR or MIR and everything worked on AST, but now all AST visitors run early and majority of them have to deal with macro calls, often by ignoring them. The second commit renames `visit_mac` to `visit_mac_call`, the corresponding structures were renamed earlier in https://github.com/rust-lang/rust/pull/69589.
2020-11-09Do not collect tokens for doc commentsVadim Petrochenkov-105/+75
2020-11-07fix(rustc_parse): ConstBlock expr spanCaleb Cartwright-1/+2
2020-11-05Fix even more URLsGuillaume Gomez-1/+1
2020-11-03rustc_ast: `visit_mac` -> `visit_mac_call`Vadim Petrochenkov-1/+1
2020-11-03rustc_ast: Do not panic by default when visiting macro callsVadim Petrochenkov-4/+0
2020-11-02Use reparsed `TokenStream` if we captured any inner attributesAaron Hill-29/+14
Fixes #78675 We now bail out of `prepend_attrs` if we ended up capturing any inner attributes (which can happen in several places, due to token capturing for `macro_rules!` arguments.
2020-10-31parser: Cleanup `LazyTokenStream` and avoid some clonesVadim Petrochenkov-37/+49
by using a named struct instead of a closure.
2020-10-30Add back missing commentsJoshua Nelson-2/+3
2020-10-30Fix even more clippy warningsJoshua Nelson-54/+40
2020-10-30Rollup merge of #78523 - estebank:fix-return-type-parse-regression, r=dtolnayYuki Okushi-13/+4
Revert invalid `fn` return type parsing change Revert one of the changes in #78379. Fix #78507.
2020-10-29Revert invalid `fn` return type parsing changeEsteban Küber-13/+4
Fix #78507.
2020-10-29Rollup merge of #78460 - varkor:turbofish-string-generic, r=lcnrYuki Okushi-4/+5
Adjust turbofish help message for const generics Types are no longer special. (This message arguably only makes sense with `min_const_generics` or more, but we'll be there soon.) r? @lcnr
2020-10-28Adjust turbofish help message for const genericsvarkor-4/+5
2020-10-28Rollup merge of #78453 - Storyyeller:patch-1, r=jonas-schievinkDylan DPC-1/+1
Fix typo in comments
2020-10-28Rollup merge of #78379 - estebank:fn-signature-parse, r=varkorDylan DPC-18/+45
Tweak invalid `fn` header and body parsing * Rely on regular "expected"/"found" parser error for `fn`, fix #77115 * Recover empty `fn` bodies when encountering `}` * Recover trailing `>` in return types * Recover from non-type in array type `[<BAD TOKEN>; LEN]`
2020-10-27Fix typo in commentsRobert Grosse-1/+1
2020-10-27Auto merge of #77502 - varkor:const-generics-suggest-enclosing-braces, ↵bors-22/+190
r=petrochenkov Suggest that expressions that look like const generic arguments should be enclosed in brackets I pulled out the changes for const expressions from https://github.com/rust-lang/rust/pull/71592 (without the trait object diagnostic changes) and made some small changes; the implementation is `@estebank's.` We're also going to want to make some changes separately to account for trait objects (they result in poor diagnostics, as is evident from one of the test cases here), such as an adaption of https://github.com/rust-lang/rust/pull/72273. Fixes https://github.com/rust-lang/rust/issues/70753. r? `@petrochenkov`
2020-10-26Suggest expressions that look like const generic arguments should be ↵varkor-22/+190
enclosed in brackets Co-Authored-By: Esteban Kuber <github@kuber.com.ar>
2020-10-26Rollup merge of #78214 - estebank:match-semicolon, r=oli-obkDylan DPC-1/+7
Tweak match arm semicolon removal suggestion to account for futures * Tweak and extend "use `.await`" suggestions * Suggest removal of semicolon on prior match arm * Account for `impl Future` when suggesting semicolon removal * Silence some errors when encountering `await foo()?` as can't be certain what the intent was *Thanks to https://twitter.com/a_hoverbear/status/1318960787105353728 for pointing this out!*
2020-10-25Tweak invalid `fn` header and body parsingEsteban Küber-9/+43
* Recover empty `fn` bodies when encountering `}` * Recover trailing `>` in return types * Recover from non-type in array type `[<BAD TOKEN>; LEN]`
2020-10-25Rely on regular "expected"/"found" parser error for `fn`Esteban Küber-12/+5
2020-10-24Auto merge of #77255 - Aaron1011:feature/collect-attr-tokens, r=petrochenkovbors-115/+115
Unconditionally capture tokens for attributes. This allows us to avoid synthesizing tokens in `prepend_attr`, since we have the original tokens available. We still need to synthesize tokens when expanding `cfg_attr`, but this is an unavoidable consequence of the syntax of `cfg_attr` - the user does not supply the `#` and `[]` tokens that a `cfg_attr` expands to. This is based on PR https://github.com/rust-lang/rust/pull/77250 - this PR exposes a bug in the current `collect_tokens` implementation, which is fixed by the rewrite.
2020-10-23Silence unnecessary `await foo?` knock-down errorEsteban Küber-1/+7
2020-10-22Only call `collect_tokens` when we have an attribute to parseAaron Hill-26/+32
2020-10-22Make inline const work for half open rangesSantiago Pastorino-8/+8
2020-10-22Make inline const work in range patternsSantiago Pastorino-6/+15
2020-10-22Rename parse_const_expr to parse_const_blockSantiago Pastorino-3/+3
2020-10-22Don't create an empty `LazyTokenStream`Aaron Hill-19/+25
2020-10-21Unconditionally capture tokens for attributes.Aaron Hill-99/+87
This allows us to avoid synthesizing tokens in `prepend_attr`, since we have the original tokens available. We still need to synthesize tokens when expanding `cfg_attr`, but this is an unavoidable consequence of the syntax of `cfg_attr` - the user does not supply the `#` and `[]` tokens that a `cfg_attr` expands to.
2020-10-21Auto merge of #77250 - Aaron1011:feature/flat-token-collection, r=petrochenkovbors-156/+171
Rewrite `collect_tokens` implementations to use a flattened buffer Instead of trying to collect tokens at each depth, we 'flatten' the stream as we go allong, pushing open/close delimiters to our buffer just like regular tokens. One capturing is complete, we reconstruct a nested `TokenTree::Delimited` structure, producing a normal `TokenStream`. The reconstructed `TokenStream` is not created immediately - instead, it is produced on-demand by a closure (wrapped in a new `LazyTokenStream` type). This closure stores a clone of the original `TokenCursor`, plus a record of the number of calls to `next()/next_desugared()`. This is sufficient to reconstruct the tokenstream seen by the callback without storing any additional state. If the tokenstream is never used (e.g. when a captured `macro_rules!` argument is never passed to a proc macro), we never actually create a `TokenStream`. This implementation has a number of advantages over the previous one: * It is significantly simpler, with no edge cases around capturing the start/end of a delimited group. * It can be easily extended to allow replacing tokens an an arbitrary 'depth' by just using `Vec::splice` at the proper position. This is important for PR #76130, which requires us to track information about attributes along with tokens. * The lazy approach to `TokenStream` construction allows us to easily parse an AST struct, and then decide after the fact whether we need a `TokenStream`. This will be useful when we start collecting tokens for `Attribute` - we can discard the `LazyTokenStream` if the parsed attribute doesn't need tokens (e.g. is a builtin attribute). The performance impact seems to be neglibile (see https://github.com/rust-lang/rust/pull/77250#issuecomment-703960604). There is a small slowdown on a few benchmarks, but it only rises above 1% for incremental builds, where it represents a larger fraction of the much smaller instruction count. There a ~1% speedup on a few other incremental benchmarks - my guess is that the speedups and slowdowns will usually cancel out in practice.
2020-10-21Rollup merge of #78118 - spastorino:inline-const-followups, r=petrochenkovYuki Okushi-1/+5
Inline const followups r? @petrochenkov Follow ups of #77124
2020-10-19Allow NtBlock to parse on check inline const next tokenSantiago Pastorino-1/+5
2020-10-19Rewrite `collect_tokens` implementations to use a flattened bufferAaron Hill-156/+171
Instead of trying to collect tokens at each depth, we 'flatten' the stream as we go allong, pushing open/close delimiters to our buffer just like regular tokens. One capturing is complete, we reconstruct a nested `TokenTree::Delimited` structure, producing a normal `TokenStream`. The reconstructed `TokenStream` is not created immediately - instead, it is produced on-demand by a closure (wrapped in a new `LazyTokenStream` type). This closure stores a clone of the original `TokenCursor`, plus a record of the number of calls to `next()/next_desugared()`. This is sufficient to reconstruct the tokenstream seen by the callback without storing any additional state. If the tokenstream is never used (e.g. when a captured `macro_rules!` argument is never passed to a proc macro), we never actually create a `TokenStream`. This implementation has a number of advantages over the previous one: * It is significantly simpler, with no edge cases around capturing the start/end of a delimited group. * It can be easily extended to allow replacing tokens an an arbitrary 'depth' by just using `Vec::splice` at the proper position. This is important for PR #76130, which requires us to track information about attributes along with tokens. * The lazy approach to `TokenStream` construction allows us to easily parse an AST struct, and then decide after the fact whether we need a `TokenStream`. This will be useful when we start collecting tokens for `Attribute` - we can discard the `LazyTokenStream` if the parsed attribute doesn't need tokens (e.g. is a builtin attribute). The performance impact seems to be neglibile (see https://github.com/rust-lang/rust/pull/77250#issuecomment-703960604). There is a small slowdown on a few benchmarks, but it only rises above 1% for incremental builds, where it represents a larger fraction of the much smaller instruction count. There a ~1% speedup on a few other incremental benchmarks - my guess is that the speedups and slowdowns will usually cancel out in practice.
2020-10-19Avoid cloning the contents of a `TokenStream` in a few placesAaron Hill-5/+5
2020-10-18Remove redundant 'static in the compilerest31-1/+1
2020-10-16Parse inline const patternsSantiago Pastorino-0/+3
2020-10-16Parse inline const expressionsSantiago Pastorino-3/+26
2020-10-16Rollup merge of #77780 - calebcartwright:cast-expr-attr-span, r=oli-obkDylan DPC-7/+17
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
2020-10-15fix off-by-one in parameter spansAndy Russell-1/+1
2020-10-15Rollup merge of #77739 - est31:remove_unused_code, r=petrochenkov,varkorYuki Okushi-16/+0
Remove unused code Rustc has a builtin lint for detecting unused code inside a crate, but when an item is marked `pub`, the code, even if unused inside the entire workspace, is never marked as such. Therefore, I've built [warnalyzer](https://github.com/est31/warnalyzer) to detect unused items in a cross-crate setting. Closes https://github.com/est31/warnalyzer/issues/2
2020-10-14Remove unused code from remaining compiler cratesest31-16/+0
2020-10-12rustc_parse: correct span on range expr with attrsCaleb Cartwright-1/+1
2020-10-12rustc_parse: correct span on cast expr with attrsCaleb Cartwright-6/+16
2020-10-11Remove unused importAaron Hill-1/+1
2020-10-11Add `relaxed_delim_match` parameterAaron Hill-16/+53
2020-10-11Allow skipping extra paren insertion during AST pretty-printingAaron Hill-7/+30
Fixes #74616 Makes progress towards #43081 Unblocks PR #76130 When pretty-printing an AST node, we may insert additional parenthesis to ensure that precedence is properly preserved in code we output. However, the proc macro implementation relies on comparing a pretty-printed AST node to the captured `TokenStream`. Inserting extra parenthesis changes the structure of the reparsed `TokenStream`, making the comparison fail. This PR refactors the AST pretty-printing code to allow skipping the insertion of additional parenthesis. Several freestanding methods are moved to trait methods on `PrintState`, which keep track of an internal `insert_extra_parens` flag. This flag is normally `true`, but we expose a public method which allows pretty-printing a nonterminal with `insert_extra_parens = false`. To avoid changing the public interface of `rustc_ast_pretty`, the freestanding `_to_string` methods are changed to delegate to a newly-crated `State`. The main pretty-printing code is moved to a new `state` module to ensure that it does not accidentally call any of these public helper functions (instead, the internal functions with the same name should be used).
2020-10-11rustc_parse: More precise spans for `tuple.0.0`Vadim Petrochenkov-7/+33
2020-10-07Detect blocks that could be struct expr bodiesEsteban Küber-15/+125
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 05:26:26 +0000