fix: parse field expr keyword field to field-expr node#22398
Conversation
|
I feel this is a wrong step to take. The reason completion fails is a bug in completion (specifically in the expansion phase, which speculative execution will fix). We shouldn't touch parsing to fix that. |
This makes the completion more coherent and helpful for climbing trees
Example
---
```rust
const _=x.ref
```
**Before this PR**
```
CONST
CONST_KW "const"
WHITESPACE " "
UNDERSCORE "_"
EQ "="
FIELD_EXPR
PATH_EXPR
PATH
PATH_SEGMENT
NAME_REF
IDENT "x"
DOT "."
ERROR
REF_KW "ref"
ERROR
SEMICOLON ";"
```
**After this PR**
```rust
CONST
CONST_KW "const"
WHITESPACE " "
UNDERSCORE "_"
EQ "="
FIELD_EXPR
PATH_EXPR
PATH
PATH_SEGMENT
NAME_REF
IDENT "x"
DOT "."
ERROR
REF_KW "ref"
SEMICOLON ";"
```
bb7cafb to
9ba7631
Compare
|
I added a bug fix example |
|
I'm aware of this bug and that this fixes it, that's why I said:
|
|
But some steps are on the original tree, not speculative tree, like expected type and name And this does make incomplete parsing more reasonable, it won't get worse |
I don't understand what you mean by that. What I'm saying is that once we have speculative execution, this bug will be fixed without any change to the parser.
Changing parsing to accept more code has many implications, and I'm opposed to that without a very good reason, especially not to aid a specific IDE feature such as completion. |
|
Okay, I've come up with a worse case: const _={
x.
let y = 2;
} |
This makes the completion more coherent and helpful for climbing trees
Example
Before this PR
After this PR
Before this PR
ty: (), name: ?After this PR
ty: &mut u8, name: ?