about summary refs log tree commit diff
path: root/crates/parser/src
AgeCommit message (Collapse)AuthorLines
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]-48/+47
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-4/+3
2021-10-03Add semicolons for consistencyAramis Razzaghipour-44/+44
`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-18/+24
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-94/+77
Attrs are syntactically valid on any expression, even if they are not allowed semantically everywhere yet.
2021-09-25fix: correct extend_to logic in parserAleksey Kladov-9/+11
Previously we swapped to events in the buffer, but that might be wrong if there aer `forward_parent` links pointing to the swapped-out node. Let's do the same via parent links instead, keeping the nodes in place
2021-09-25simplify attribute parsingAleksey Kladov-31/+16
2021-09-25minor: more condensed testsAleksey Kladov-11/+7
2021-09-25minor: link my own pratt parsing article :-)Aleksey Kladov-2/+1
2021-09-25minor: more focusted testsAleksey Kladov-22/+13
2021-09-25minor: more readable codeAleksey Kladov-13/+11
2021-09-19internal: more focused tests for const argumentsAleksey Kladov-10/+22
2021-09-19minor: simplifyAleksey Kladov-20/+7
2021-09-19minor: simplifyAleksey Kladov-11/+3
2021-09-19fix: don't allow two turbo-fishes in generic argumentsAleksey Kladov-1/+0
2021-09-19minor: improve readabilityAleksey Kladov-10/+14
2021-09-19minor: reduce duplicationAleksey Kladov-21/+5
2021-09-18fix: correctly handle jointnessAleksey Kladov-1/+1
2021-09-18minor: improve readabilityAleksey Kladov-15/+17
2021-09-18internal: better namingAleksey Kladov-60/+60
2021-09-18internal: parser cleanupAleksey Kladov-45/+44
2021-09-18internal: minimize use_tree parser testsAleksey Kladov-65/+28
The code here is intentionally dense and does exactly what is written. Explaining semantic difference between Rust 2015 and 2018 doesn't help with understanding syntax. Better to just add more targeted tests.
2021-09-18internal: parser cleanupsAleksey Kladov-19/+12
2021-09-18internal: more focused trait item parsing testsAleksey Kladov-7/+18
2021-09-18intenral: more local tests for staticsAleksey Kladov-5/+8
2021-09-18minor: cleanup const parsingAleksey Kladov-9/+9
2021-09-18minor: better test placementAleksey Kladov-7/+6
2021-09-18internal: cleanup adt parsingAleksey Kladov-29/+18
2021-09-18internal: cleanup item parsingAleksey Kladov-59/+44
2021-09-18minor: parser cleanupAleksey Kladov-21/+20
2021-09-17minor: simplifyAleksey Kladov-7/+1
2021-09-17minor: cleanupAleksey Kladov-3/+3
2021-09-17minor: simplifyAleksey Kladov-3/+3
2021-09-17internal: more local parsing tests for macrosAleksey Kladov-9/+4
2021-09-17internal: more focused parsing testsAleksey Kladov-64/+46
2021-09-17internal: more local test for mod itemAleksey Kladov-22/+24
2021-09-17internal: more local parsing testsAleksey Kladov-2/+6
2021-09-17internal: parser cleanupsAleksey Kladov-37/+36
2021-09-13internal: simplifyAleksey Kladov-3/+4
2021-09-13internal: fix bugs in tests by simplifying codeAleksey Kladov-5/+6
2021-09-06minor: modernizeAleksey Kladov-6/+5
2021-09-06internal: make name consistent with usageAleksey Kladov-47/+50
2021-09-05internal: remove accidental code re-useAleksey Kladov-4/+0
FragmentKind played two roles: * entry point to the parser * syntactic category of a macro call These are different use-cases, and warrant different types. For example, macro can't expand to visibility, but we have such fragment today. This PR introduces `ExpandsTo` enum to separate this two use-cases. I suspect we might further split `FragmentKind` into `$x:specifier` enum specific to MBE, and a general parser entry point, but that's for another PR!
2021-08-30internal: improve styleAleksey Kladov-21/+19
Group related stuff together, use only on path for parsing extern blocks (they actually have modifiers). Perhaps we should get rid of items_without_modifiers altogether? Better to handle these kinds on diagnostics in validation layer...
2021-08-30fix: avoid panic when parsing extern blockAleksey Kladov-13/+13
closes #10083
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 03:41:02 +0000