| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This is actually allowed by the `rustc` parser but most attributes will
fail later due to attributes on expressions being experimental.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 `;`.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
1415: fix: specialization r=matklad a=csmoe
Closes #1402
r? @matklad
Co-authored-by: csmoe <[email protected]>
|
| |
| |
| |
| | |
Change-Id: Ic5d2767e8781568d76d4d0013cd6081e95ae8a95
|
| |
| |
| |
| | |
Change-Id: I45a856d74fb616d3bce33050f9e69d327186bd59
|
|/
|
|
| |
Change-Id: I6e20e0163fa545de37226c1561b3b7103615626c
|
| |
|
|
|
|
| |
Change-Id: I14e1bc628b9d2dfdb1f40de3d3707f4e872767f2
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1082: Async block in argument position r=matklad a=andreytkachenko
Fixes case when async block appears in argument position
Co-authored-by: Andrey Tkachenko <[email protected]>
|
| | |
|
|/ |
|
|
|
|
|
| |
This also unifies parsing of WHERE_PRED bounds, now Lifetime bounds will also be
parsed using TYPE_BOUND_LIST
|
|\
| |
| |
| |
| |
| |
| |
| | |
1072: recognize async move blocks r=matklad a=memoryruins
closes #1053
Co-authored-by: memoryruins <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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 +.
|
|/ |
|
|
|
|
| |
Fixes #1020
|
| |
|
| |
|
|
|
|
| |
unallowed types of expression statement
|
|
|
|
|
|
| |
A top level expression is either
- a expression statement or
- the last expression in a block
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| |
| |
| |
| |
| | |
- Fix pub_expr
- Fix incorrect parsing of crate::path
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
| |/
|/| |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
985: simplify parsing blocks a bit r=pcpthm a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |/ |
|
|/ |
|
| |
|