1848: Parse `..` as a full pattern r=matklad a=ecstatic-morse
Resolves#1479.
This PR implements [RFC 2707](https://github.com/rust-lang/rfcs/pull/2707) in the parser. It introduces a new `DotDotPat` AST node modeled on `PlaceholderPat` and changes the parsing of tuple and slice patterns to conform to the RFC.
Notably, this PR does *not* change the resulting AST when `..` appears in a struct pattern (e.g. `Struct { a, b: c, .. }`). I *think* this is the behavior mandated by RFC 2707, but someone should confirm this.
Co-authored-by: Dylan MacKenzie <ecstaticmorse@gmail.com>
Parser has the invariant that `{}` are balanced.
Previous code tried (unsucesfuly) maintain the same invariant for
`$()` as well, but it was done in a rather ad-hoc manner: it's not at
all obvious that it is possible to maintain both invariants!
Named structs can have `box` patterns that will bind to their fields.
This is similar to the behavior of the `ref` and `mut` fields, but is at
least a little bit surprising.
1661: Parse function parameters attributes r=matklad a=eupn
Fixes#1397. The [RFC-2565](https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md) specifies `#[attributes]` to function parameters:
```rust
fn foo(#[attr] a, #[unused] b, #[must_use] ...) {
// ...
}
```
This PR adds those attributes into grammar and to the parser, extending corresponding inline tests.
Co-authored-by: Evgenii P <eupn@protonmail.com>
This wasn't a right decision in the first place, the feature flag was
broken in the last rustfmt release, and syntax highlighting of imports
is more important anyway
Array members are allow to have attributes such as `#[cfg]`.
This is a bit tricky as we don't know if the first expression is an
initializer or a member until we encounter a `;`. This reuses a trick
from `stmt` where we remember if we saw an attribute and then raise an
error if the first expression ends up being an initializer.
This isn't perfect as the error isn't correctly located on the attribute
or initializer; it ends up immediately after the `;`.
1328: Change TokenSource to iteration based r=matklad a=edwin0cheng
This PR change the `TokenSource` trait from random access to be an iteration based trait:
```rust
/// `TokenSource` abstracts the source of the tokens parser operates one.
///
/// Hopefully this will allow us to treat text and token trees in the same way!
pub trait TokenSource {
fn current(&self) -> Token;
/// Lookahead n token
fn lookahead_nth(&self, n: usize) -> Token;
/// bump cursor to next token
fn bump(&mut self);
/// Is the current token a specified keyword?
fn is_keyword(&self, kw: &str) -> bool;
}
/// `TokenCursor` abstracts the cursor of `TokenSource` operates one.
#[derive(Debug, Copy, Clone, Eq, PartialEq)]
pub struct Token {
/// What is the current token?
pub kind: SyntaxKind,
/// Is the current token joined to the next one (`> >` vs `>>`).
pub is_jointed_to_next: bool,
}
```
Note that the refactoring based on this new trait will be separated to incoming PRs
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
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 <edwin0cheng@gmail.com>
1105: [WIP] Implement ra_mbe meta variables support r=matklad a=edwin0cheng
This PR implements the following meta variable support in `ra_mba` crate (issue #720):
- [x] `path`
- [ ] `expr`
- [ ] `ty`
- [ ] `pat`
- [ ] `stmt`
- [ ] `block`
- [ ] `meta`
- [ ] `item`
*Implementation Details*
In the macro expanding lhs phase, if we see a meta variable type, we try to create a `tt:TokenTree` from the remaining input. And then we use a special set of `ra_parser` to parse it to `SyntaxNode`.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
1082: Async block in argument position r=matklad a=andreytkachenko
Fixes case when async block appears in argument position
Co-authored-by: Andrey Tkachenko <andreytkachenko64@gmail.com>
1081: Async closure syntax r=matklad a=robojumper
Fixes#1080.
Also fixes an error introduced by #1072 where something like `async move "foo"` in expression position would trigger the assertion in `block_expr`.
Co-authored-by: robojumper <robojumper@gmail.com>
Now bounds inside a path are parsed as DYN_TRAIT_TYPE, previously they would be
parsed as `PATH_TYPE` followed by `TYPE_BOUND_LIST`.
Basically this means `Box<T + 'f>` is now parsed almost the same as
`Box<dyn T + 'f>` with the exception of not having the `dyn` keyword.
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 +.
991: Use Marker argument for item parsers r=matklad a=pcpthm
Before doing this for expressions, I found that the pattern (Marker argument) should be applied to the item parsers because visiblity and modifiers are parsed in a separate function.
Fixed some parser bugs:
- Fix pub_expr: `pub 42;` was allowed.
- Fix incorrect parsing of crate::path: incorrectly parsed as `crate` as a visibility.
Co-authored-by: pcpthm <pcpthm@gmail.com>
987: Refactor maybe_item to use Marker argument r=pcpthm a=pcpthm
As suggested at <https://github.com/rust-analyzer/rust-analyzer/pull/980#issuecomment-473659745>.
For expression paring functions, changing signature
- from `fn(&mut Parser) -> Option<CompletedMarker>` to `fn(&mut Parser, Marker) -> Result<CompletedMarker, Marker>`
- from `fn(&mut Parser) -> CompletedMarker` to `fn(&mut Parser, Marker) -> CompletedMarker`
is my plan.
Co-authored-by: pcpthm <pcpthm@gmail.com>
983: support remainder assignment operator r=matklad a=JeanMertz
`%=` was returning errors for me, turns out it wasn't added as a valid assignment operation.
I'm not sure what the best location would be to add a test for this. Please let me know and I'll add one.
Co-authored-by: Jean Mertz <jean@mertz.fm>
