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.
Implement `stability_implications` without a visitor.
Since https://github.com/rust-lang/rust/pull/143845, the `Annotator` visitor was a no-op when the crate is not staged_api. This PR avoids using a visitor altogether, making `stability_implications` truly a no-op in most cases.
Refactor codegen backends in bootstrap
This PR refactors the codegen backend steps, in preparation to make more progress on the integration of the GCC codegen backend in bootstrap. It does several things:
1) Splits the `CodegenBackend` step into two, one for clif and another one for gcc. Even though their code is mostly similar, that's IMO mostly fake similarity, and they do (or will) ultimately require different handling. This was already visible in the requirement of building GCC for cg_gcc, of course.
2) It is now possible to build both backends (and dist cranelift) even if they are not specified in `rust.codegen-backends`. It was quite weird that it wasn't possible to even invoke the corresponding codegen backend if the backend wasn't specified in that array, as that array should ideally only change defaults (see later below).
3) Changes the path specification of these steps to an alias. In other words, instead of `compiler/rustc_codegen_cranelift`, the step is now built only using `rustc_codegen_cranelift` or `cg_clif`. This is done to avoid an annoying clash with `x build compiler`, which would otherwise build both codegen backends after the 2) change.
4) Made the copying of codegen backend artifacts more explicit, in particular in the `Assemble` step.
5) Codifies the semantics of `rust.codegen-backends`, which now only affects the defaults of whether a codegen backend will be included in rustc's sysroot and whether it will be disted in `x dist` by default. We can change the behavior later, e.g. to dist cranelift by default in `x dist` once it becomes stabilized. Currently I left the existing behavior that we use on CI, I just tried to document it better.
I don't think that this requires a change tracker entry, because the defaults should work the same as before. It is just now possible to do `x build/dist rustc_codegen_cranelift` even if CLIF is not in the `codegen-backends` array. It is no longer possible to do `./x build compiler/rustc_codegen_cranelift` though, not sure if that requires a change tracker entry.
There is one thing that I didn't touch yet, and that is the fact that `rust.codegen-backends` not only affects the default behavior of `x dist` w.r.t. Cranelift, but also of `x test`. In other words, `x test rustc_codegen_cranelift` still does not hing if cranelift isn't in `rust.codegen-backends`. I plan to take a look at this once I get to refactoring the test steps.
r? `@jieyouxu`
