Usually, this occurs when preparing to input a method name
However, once an identifier is entered, it is not reasonable for the parsing result to change from `CallExpr(FieldExpr())` to `MethodCallExpr()`
Example
---
```rust
fn foo() {
x.
()
}
```
**Before this PR**:
```text
SOURCE_FILE
FN
FN_KW "fn"
WHITESPACE " "
NAME
IDENT "foo"
PARAM_LIST
L_PAREN "("
R_PAREN ")"
WHITESPACE " "
BLOCK_EXPR
STMT_LIST
L_CURLY "{"
WHITESPACE "\n "
CALL_EXPR
FIELD_EXPR
PATH_EXPR
PATH
PATH_SEGMENT
NAME_REF
IDENT "x"
DOT "."
WHITESPACE "\n "
ARG_LIST
L_PAREN "("
R_PAREN ")"
WHITESPACE "\n"
R_CURLY "}"
WHITESPACE "\n"
error 17: expected field name or number
```
**After this PR**:
```text
SOURCE_FILE
FN
FN_KW "fn"
WHITESPACE " "
NAME
IDENT "foo"
PARAM_LIST
L_PAREN "("
R_PAREN ")"
WHITESPACE " "
BLOCK_EXPR
STMT_LIST
L_CURLY "{"
WHITESPACE "\n "
METHOD_CALL_EXPR
PATH_EXPR
PATH
PATH_SEGMENT
NAME_REF
IDENT "x"
DOT "."
WHITESPACE "\n "
ARG_LIST
L_PAREN "("
R_PAREN ")"
WHITESPACE "\n"
R_CURLY "}"
WHITESPACE "\n"
error 17: expected method name, field name or number
```
Example
---
```rust
static C<i32>: u32 = 0;
```
->
```diff
-error 8: missing type for `const` or `static`
+error 8: `static` may not have generic parameters
```
---
```rust
const C = 0;
```
->
```diff
-error 7: missing type for `const` or `static`
+error 7: missing type for `const`
```
---
```rust
static C = 0;
```
->
```diff
-error 8: missing type for `const` or `static`
+error 8: missing type for `static`
```
The rustc AST allows both `for<>` binders and `?` polarity
modifiers in trait bounds, but they are parsed in a specific
order and validated for correctness:
1. `for<>` binder is parsed first.
2. Polarity modifiers (`?`, `!`) are parsed second.
3. The parser validates that binders and polarity modifiers
do not conflict:
```rust
if let Some(binder_span) = binder_span {
match modifiers.polarity {
BoundPolarity::Maybe(polarity_span) => {
// Error: "for<...> binder not allowed with ? polarity"
}
}
}
```
This implies:
- `for<> ?Sized` → Valid syntax. Invalid semantics.
- `?for<> Sized` → Invalid syntax.
However, rust-analyzer incorrectly had special-case logic that
allowed `?for<>` as valid syntax. This fix removes that incorrect
special case, making rust-analyzer reject `?for<> Sized` as a
syntax error, matching rustc behavior.
This has caused confusion in other crates (such as syn) which
rely on these files to implement correct syntax evaluation.
Including:
- Infer `label {}` and `const` operands.
- Correctly handle unsafe check inside `label {}`.
- Fix an embarrassing parser typo that cause labels to never be part of the AST
When running `cargo codegen` the `crates/parser/test_data/generated/runner.rs` file is only updated when some file in `crates/parser/test_data/inline` changes. However this is not sufficient in all cases
Which caused the macros of the popular `tracing` crate to not offer completions.
The reason is rather complicated: it boils down to macro ignoring their input and completion always choosing the first expansion.
This mainly aids in error recovery but also makes it a bit easier to handle lifetime resolution.
While doing so it also came apparent that we were not actually lowering lifetime outlives relationships within lifetime parameter declaration bounds, so this fixes that.
