| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | |
|
|\| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
1087: More future-proof comment kind r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / / / / |
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
1085: add ast::tokens r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
1084: remove dead code r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
1050: Intelligently add parens when inlining local varaibles r=matklad a=gfreezy
fixed this. https://github.com/rust-analyzer/rust-analyzer/pull/1037#discussion_r268627141
Co-authored-by: gfreezy <[email protected]>
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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]>
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
1067: Take number of arguments at the call-site into account for signature help r=matklad a=kjeremy
Fixes #1065
Co-authored-by: kjeremy <[email protected]>
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixes #1065
|
|\ \ \ \ \ \
| |_|/ / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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 <[email protected]>
|
| | | | | | |
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
1078: rewrite syntax trees r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / / / / |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
1038: Add WherePred to allow predicate access in WhereClause r=matklad a=vipentti
Lifetime bounds in where predicates are now also parsed into `TYPE_BOUND_LIST` to allow unified access to bounds.
Co-authored-by: Ville Penttinen <[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]>
|
| | | | | | |
|
| | |_|_|/
| |/| | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
1077: Improve parsing of type bounds r=matklad a=vipentti
This adds new TYPE_BOUND_LIST and TYPE_BOUND syntax kinds. 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 +.
Basically now the generic params `struct S<T: 'a + ?Sized + (Copy)>;` in will be parsed as
```
TYPE_PARAM_LIST@[8; 33)
L_ANGLE@[8; 9)
TYPE_PARAM@[9; 32)
NAME@[9; 10)
IDENT@[9; 10) "T"
COLON@[10; 11)
WHITESPACE@[11; 12)
TYPE_BOUND_LIST@[12; 32)
TYPE_BOUND@[12; 14)
LIFETIME@[12; 14) "'a"
WHITESPACE@[14; 15)
PLUS@[15; 16)
WHITESPACE@[16; 17)
TYPE_BOUND@[17; 23)
QUESTION@[17; 18)
PATH_TYPE@[18; 23)
PATH@[18; 23)
PATH_SEGMENT@[18; 23)
NAME_REF@[18; 23)
IDENT@[18; 23) "Sized"
WHITESPACE@[23; 24)
PLUS@[24; 25)
WHITESPACE@[25; 26)
TYPE_BOUND@[26; 32)
L_PAREN@[26; 27)
PATH_TYPE@[27; 31)
PATH@[27; 31)
PATH_SEGMENT@[27; 31)
NAME_REF@[27; 31)
IDENT@[27; 31) "Copy"
R_PAREN@[31; 32)
R_ANGLE@[32; 33)
```
Previously it was parsed, with the paths nested:
```
TYPE_PARAM_LIST@[8; 33)
L_ANGLE@[8; 9)
TYPE_PARAM@[9; 32)
NAME@[9; 10)
IDENT@[9; 10) "T"
COLON@[10; 11)
WHITESPACE@[11; 12)
LIFETIME@[12; 14) "'a"
WHITESPACE@[14; 15)
PLUS@[15; 16)
WHITESPACE@[16; 17)
QUESTION@[17; 18)
PATH_TYPE@[18; 32)
PATH@[18; 23)
PATH_SEGMENT@[18; 23)
NAME_REF@[18; 23)
IDENT@[18; 23) "Sized"
WHITESPACE@[23; 24)
PLUS@[24; 25)
WHITESPACE@[25; 26)
L_PAREN@[26; 27)
PATH_TYPE@[27; 31)
PATH@[27; 31)
PATH_SEGMENT@[27; 31)
NAME_REF@[27; 31)
IDENT@[27; 31) "Copy"
R_PAREN@[31; 32)
R_ANGLE@[32; 33)
```
Looking for feedback.
Co-authored-by: Ville Penttinen <[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 +.
|
|/ / / / / |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
1075: Fix parsing <= in type_args r=matklad a=vipentti
Fixes #1074
Co-authored-by: Ville Penttinen <[email protected]>
|
|/ / / / / |
|
|/ / / / |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1071: Fix emacs-lsp runnables support with native json r=matklad a=flodiebold
(In that case args is a vector, which string-join doesn't like.)
Co-authored-by: Florian Diebold <[email protected]>
|
|/ / /
| | |
| | |
| | | |
(In that case args is a vector, which string-join doesn't like.)
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1070: Support extern_crate_self r=matklad a=memoryruins
closes #1069
Co-authored-by: memoryruins <[email protected]>
|
| | | | |
|
|/ / / |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
1066: update salsa some more r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1063: :arrow_up: salsa r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1061: Use EXE extension for pre-commit hook on Window r=matklad a=hban
Tested on Git Bash, CMD and Powershell.
Closes: #875
Co-authored-by: Hrvoje Ban <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1052: Flip binary expression assist r=matklad a=marcogroppo
Adds an assist that can flip these binary comparison operators: `==`, `!=`, `>`, `>=`, `<`, `<=`.
This is a small extension to the 'flip ==' assist.
In theory we could easily flip ANY binary expression, but I'm not sure it would be a good idea (IMHO we should try not to change the meaning of the expression).
Does it make sense?
Co-authored-by: Marco Groppo <[email protected]>
|