about summary refs log tree commit diff
path: root/crates/parser/src/grammar
AgeCommit message (Collapse)AuthorLines
2022-06-02fix: parsing of `?` opt-out trait boundsXFFXFF-0/+6
thanks to Veykril
2022-05-13Revert "Auto merge of #12149 - jonas-schievink:literally-just-a-literal, ↵Jonas Schievink-46/+8
r=jonas-schievink" This reverts commit cc9ae2b89e01a30e441371b9fd3376c3d03a475f, reversing changes made to 7dfd1cb572d8d4fd951237361e43ecddd9c9a852.
2022-05-05Maybe everything else *should* have to deal with itJonas Schievink-10/+5
2022-05-05Indicate the number of float tokens in the first tokenJonas Schievink-11/+34
2022-05-05Wrap floats in token trees in `FLOAT_LITERAL` nodeJonas Schievink-12/+19
2022-05-05Add testsJonas Schievink-0/+2
2022-05-05Split float literal tokens at the `.`Jonas Schievink-8/+13
2022-05-05Wrap float literals in their own nodeJonas Schievink-1/+7
2022-04-27fix: Use pattern recovery set when parsing ident patternsLukas Wirth-9/+6
2022-04-17update parser to support associated const equalityXFFXFF-3/+11
2022-04-10Parse for<'a> closure syntaxLukas Wirth-42/+38
2022-04-05Wrap macros in expr position in `MacroExpr` nodeJonas Schievink-2/+4
2022-04-01recover from missing type annotationhkalbasi-0/+6
2022-03-31Remove parser restriction on varargs positioningJonas Schievink-26/+19
2022-03-11refactor: Rename and move const_arg_pathSteven Joruk-2/+4
It wasn't testing the `const_arg` code path, it was actually hitting const_param's default value code path, so move it to the right place and rename it.
2022-03-11refactor: Rename const_arg_content to const_arg_exprSteven Joruk-3/+3
2022-03-11fix: Stop wrapping ConstParam's default values in ConstArgSteven Joruk-12/+17
This was causing ConstParam::default_val to always return None for block expressions. CONST_ARG@24..29 BLOCK_EXPR@24..29 ...
2022-03-10Add support for new `where` clause location in associated types.Dario Nieuwenhuis-1/+6
A recent Rust nightly changed it: https://github.com/rust-lang/rust/issues/89122 This allows both the old and new location.
2022-03-05fix: Recognize `Self` as a proper keywordLukas Wirth-4/+5
2022-03-02Parse destructuring assignmentChayim Refael Friedman-1/+21
The only patterns we should parse are `..` in structs and `_`: the rest are either not supported or already valid expressions.
2022-02-21Parse `let` expressions in order to support `let` chainsChayim Refael Friedman-20/+23
We still need to reject freestanding `let` expressions: see https://github.com/rust-analyzer/rust-analyzer/issues/11320#issuecomment-1018212465.
2022-02-14Fix stylebellau-9/+5
2022-02-13oops, remove printlnbellau-1/+0
2022-02-13fix handle static async and static async movebellau-3/+18
2022-02-12Fix stylebellau-1/+1
2022-02-12support static move toobellau-3/+5
2022-02-12Fix stylesbellau-1/+1
2022-02-12Fix Immovable generator syntax (static ||) not recognized #11448bellau-1/+5
2021-12-29parse empty statemet as statemetnAleksey Kladov-6/+4
2021-12-29renameAleksey Kladov-18/+17
2021-12-29compressAleksey Kladov-3/+4
2021-12-26internal: move inline parser tests to parser crateAleksey Kladov-7/+0
2021-12-12Switch parser to use tokensAleksey Kladov-11/+8
2021-11-18fix: parse the range pat inside the tuple patzhoufan-1/+6
2021-11-10Handle pub tuple fields in tuple structsAdam Bratschi-Kaye-3/+3
The current implementation will throw a parser error for tuple structs that contain a pub tuple field. For example, ```rust struct Foo(pub (u32, u32)); ``` is valid Rust, but rust-analyzer will throw a parser error. This is because the parens after `pub` is treated as a visibility context. Allowing a tuple type to follow `pub` in the special case when we are defining fields in a tuple struct can fix the issue.
2021-10-23internal: remove unused dollarsAleksey Kladov-28/+1
2021-10-19internal: Parse const trait boundsLukas Wirth-6/+16
2021-10-07Support `let...else`Jonas Schievink-0/+10
2021-10-06parser: fix parsing of macro call inside generic argscynecx-1/+4
2021-10-06Merge #10420bors[bot]-25/+43
10420: Parse outer attributes on StructPatternEtCetera r=jonas-schievink a=XFFXFF Try to fix https://github.com/rust-analyzer/rust-analyzer/issues/8610 Related pr in ungrammer: https://github.com/rust-analyzer/ungrammar/pull/41 Co-authored-by: zhoufan <1247714429@qq.com>
2021-10-05Merge #10440bors[bot]-37/+37
10440: Fix Clippy warnings and replace some `if let`s with `match` r=Veykril a=arzg I decided to try fixing a bunch of Clippy warnings. I am aware of this project’s opinion of Clippy (I have read both [rust-lang/clippy#5537](https://github.com/rust-lang/rust-clippy/issues/5537) and [rust-analyzer/rowan#57 (comment)](https://github.com/rust-analyzer/rowan/pull/57#discussion_r415676159)), so I totally understand if part of or the entirety of this PR is rejected. In particular, I can see how the semicolons and `if let` vs `match` commits provide comparatively little benefit when compared to the ensuing churn. I tried to separate each kind of change into its own commit to make it easier to discard certain changes. I also only applied Clippy suggestions where I thought they provided a definite improvement to the code (apart from semicolons, which is IMO more of a formatting/consistency question than a linting question). In the end I accumulated a list of 28 Clippy lints I ignored entirely. Sidenote: I should really have asked about this on Zulip before going through all 1,555 `if let`s in the codebase to decide which ones definitely look better as `match` :P Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
2021-10-04make Some(1..) parsedzhoufan-3/+8
2021-10-03Fix miscellaneous Clippy lintsAramis Razzaghipour-2/+2
2021-10-03Add semicolons for consistencyAramis Razzaghipour-35/+35
`clippy::semicolon_if_nothing_returned`
2021-10-03move outer_attrs call before the matchzhoufan-15/+8
2021-10-02minorAleksey Kladov-1/+1
2021-10-02Parse outer attributes on StructPatternEtCeterazhoufan-21/+46
2021-09-26internal: more reasonable grammar for blocksAleksey Kladov-17/+23
Consider these expples { 92 } async { 92 } 'a: { 92 } #[a] { 92 } Previously the tree for them were BLOCK_EXPR { ... } EFFECT_EXPR async BLOCK_EXPR { ... } EFFECT_EXPR 'a: BLOCK_EXPR { ... } BLOCK_EXPR #[a] { ... } As you see, it gets progressively worse :) The last two items are especially odd. The last one even violates the balanced curleys invariant we have (#10357) The new approach is to say that the stuff in `{}` is stmt_list, and the block is stmt_list + optional modifiers BLOCK_EXPR STMT_LIST { ... } BLOCK_EXPR async STMT_LIST { ... } BLOCK_EXPR 'a: STMT_LIST { ... } BLOCK_EXPR #[a] STMT_LIST { ... }
2021-09-25feat: allow attributes on all expressionsAleksey Kladov-92/+74
Attrs are syntactically valid on any expression, even if they are not allowed semantically everywhere yet.
2021-09-25simplify attribute parsingAleksey Kladov-10/+4
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 12:30:16 +0000