| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We treat macro calls as expressions (there's appropriate Into impl),
which causes problem if there's expresison and non-expression macro in
the same node (like in the match arm).
We fix this problem by nesting macor patterns into another node (the
same way we nest path into PathExpr or PathPat). Ideally, we probably
should add a similar nesting for macro expressions, but that needs
some careful thinking about macros in blocks: `{ am_i_expression!() }`.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
- Handle const generics type args
- Fix issue with const generic as first parameter in trait impl
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2641: Parse const generics r=matklad a=roblabla
Adds very primitive support for parsing const generics (`const IDENT: TY`) so that rust-analyzer stops complaining about the syntax being invalid.
Fixes #1574
Fixes #2281
Co-authored-by: roblabla <[email protected]>
|
| |
| |
| |
| |
| | |
Fixes #1574
Fixes #2281
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
Although structs and unions have the same syntax and differ only in
the keyword, re-using the single syntax node for both of them leads to
confusion in practice, and propagates further down the hir in an
upleasent way.
Moreover, static and consts also share syntax, but we use different
nodes for them.
|
|
|
|
| |
#1856
|
| |
|
|
|
|
| |
This is modeled on `PlaceholderPat`.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Change-Id: I45a856d74fb616d3bce33050f9e69d327186bd59
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1138: Add L_DOLLAR and R_DOLLAR r=matklad a=edwin0cheng
As discussion in issue https://github.com/rust-analyzer/rust-analyzer/issues/1132 and PR #1125 , this PR add 2 `Syntax::Kind` : `L_DOLLAR` and `R_DOLLAR` for representing `Delimiter::None` in mbe and proc_marco. By design, It should not affect the final syntax tree, and will be discard in `TreeSink`.
My original idea is handling these 2 tokens case by case, but i found that they will appear in every place in the parser (imagine `tt` matcher). So this PR only handle it in `Parser::do_bump` and `Parser::start`, although It will not fix the `expr` matcher executing order problem in original idea.
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
|/ |
|
|
|
|
|
|
| |
These are now used when parsing type bounds. In addition parsing paths inside a
bound now does not recursively parse paths, rather they are treated as separate
bounds, separated by +.
|
| |
|
| |
|
|
|