rustdoc has a separate environment variable for banning warnings, so
set that in the GitHub action configuration.
https://github.com/rust-lang/cargo/issues/8424#issuecomment-1070988443
Fix all the rustdoc warnings on unknown types or functions. I've
updated references wherever it's obvious, otherwise I've replaced the
rustdoc link with plain backticks.
There were also some cases where rustdoc links referred to private
APIs. I've disabled the rustdoc private API warning in those crates.
- Discussed in https://github.com/rust-lang/rust-analyzer/issues/21107
- Avoids activating an `attributes` feature to crates that do not use it
- Updates the 6 crates that use attributes feature to specify it in
their Cargo.toml: {hir,hir-def,hir-ty,ide-assists,ide-db,project-model}
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.
Even when at curly braces, otherwise the parser can get stuck.
This has happened in the past in #18625, but it was just worked around instead of handling the root of the problem. Now this happened again in #20171. IMO we can't let `err_and_bump()` not bump, that's too confusing and invites errors. We can (as I did) workaround the worse recovery instead.
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
