Avoid unnecessary `new_adt`/`new_fn_def` calls.
They can be skipped if there are no arguments, avoiding the "relate" operation work and also the subsequent interning.
r? `@ghost`
No longer need `alloca`s for consuming `Result<!, i32>` and similar
In optimized builds GVN gets rid of these already, but in `opt-level=0` we actually make `alloca`s for this, which particularly impacts `?`-style things that use actually-only-one-variant types like this.
While doing so, rewrite `LocalAnalyzer::process_place` to be non-recursive, solving a 6+ year old FIXME.
r? codegen
Let `codegen_transmute_operand` just handle everything
When combined with rust-lang/rust#143720, this means `rvalue_creates_operand` can just return `true` for *every* `Rvalue`. (A future PR could consider removing it, though just letting it optimize out is fine for now.)
It's nicer anyway, IMHO, because it avoids needing the layout checks to be consistent in the two places, and thus is an overall reduction in code. Plus it's a more helpful building block when used in other places this way.
(TBH, it probably would have been better to have it this way the whole time, but I clearly didn't understand `rvalue_creates_operand` when I originally wrote rust-lang/rust#109843.)
Skip walking into param-env component if it has no placeholder/re-var
Although it only provides a minor perf improvement, it seems like it could matter in more pathological cases.
Do not run per-module late lints if they can be all skipped
We run ~70 late lints for all dependencies even if they use `--cap-lints=allow`, which seems wasteful. It looks like these lints are super fast (unlike early lints), but still.
r? `@ghost`
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#142569 (Suggest clone in user-write-code instead of inside macro)
- rust-lang/rust#143401 (tests: Don't check for self-printed output in std-backtrace.rs test)
- rust-lang/rust#143424 (clippy fix: rely on autoderef)
- rust-lang/rust#143970 (Update core::mem::copy documentation)
- rust-lang/rust#143979 (Test fixes for Arm64EC Windows)
- rust-lang/rust#144200 (Tweak output for non-`Clone` values moved into closures)
- rust-lang/rust#144209 (Don't emit two `assume`s in transmutes when one is a subset of the other)
- rust-lang/rust#144314 (Hint that choose_pivot returns index in bounds)
- rust-lang/rust#144340 (UI test suite clarity changes: Rename `tests/ui/SUMMARY.md` and update rustc dev guide on `error-pattern`)
- rust-lang/rust#144368 (resolve: Remove `Scope::CrateRoot`)
- rust-lang/rust#144390 (Remove dead code and extend test coverage and diagnostics around it)
- rust-lang/rust#144392 (rustc_public: Remove movability from `RigidTy/AggregateKind::Coroutine`)
r? `@ghost`
`@rustbot` modify labels: rollup
rustc_public: Remove movability from `RigidTy/AggregateKind::Coroutine`
Part of rust-lang/rust#119174 .
I think we should be good now to sync this change in rustc_public.
Remove dead code and extend test coverage and diagnostics around it
I was staring a bit at the `dont_niche_optimize_enum` variable and figured out that part of it is dead code (at least today it is). I changed the diagnostic and test around the code that makes that part dead code, so everything that makes removing that code sound is visible in this PR
Tweak output for non-`Clone` values moved into closures
When we encounter a non-`Clone` value being moved into a closure, try to find the corresponding type of the binding being moved, if it is a `let`-binding or a function parameter. If any of those cases, we point at them with the note explaining that the type is not `Copy`, instead of giving that label to the place where it is captured. When it is a `let`-binding with no explicit type, we point at the initializer (if it fits in a single line).
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:14:25
|
13 | fn do_stuff(foo: Option<Foo>) {
| --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
| |
| captured outer variable
14 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
15 | if foo.map_or(false, |f| f.foo()) {
| --- variable moved due to use in coroutine
```
instead of
```
error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure
--> f111.rs:14:25
|
13 | fn do_stuff(foo: Option<Foo>) {
| --- captured outer variable
14 | require_fn_trait(|| async {
| -- ^^^^^ `foo` is moved here
| |
| captured by this `Fn` closure
15 | if foo.map_or(false, |f| f.foo()) {
| ---
| |
| variable moved due to use in coroutine
| move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait
```
Test fixes for Arm64EC Windows
* `tests/ui/cfg/conditional-compile-arch.rs` needs an Arm64EC case.
* `tests/ui/runtime/backtrace-debuginfo.rs` should skip Arm64EC as it suffers from the same truncated backtraces as Arm64 Windows.
* `tests/ui/linkage-attr/incompatible-flavor.rs` is a general issue: it assumes that the Rust compiler is always built with the x86 target enabled in the backend, but I only enabled AArch64 when building locally to speed up the LLVM compilation.
tests: Don't check for self-printed output in std-backtrace.rs test
The `Display` implementation for `Backtrace` used to print
stack backtrace:
but that print was since removed. See https://github.com/rust-lang/backtrace-rs/pull/286 and https://github.com/rust-lang/rust/pull/69042. To make the existing test pass, the print was added to the test instead. But it doesn't make sense to check for something that the test itself does since that will not detect any regressions in the implementation of `Backtrace`.
What the test _should_ check is that "stack backtrace:" is _not_ printed in `Display` of `Backtrace`. So do that instead.
This is one small steps towards resolving https://github.com/rust-lang/rust/issues/71706. The next steps after this step involves extending and hardening that test further.
Various refactors to the LTO handling code (part 2)
Continuing from https://github.com/rust-lang/rust/pull/143388 this removes a bit of dead code and moves the LTO symbol export calculation from individual backends to cg_ssa.
We lost the following comment during refactorings:
The current code for niche-filling relies on variant indices instead of actual discriminants, so enums with explicit discriminants (RFC 2363) would misbehave.
Enforce that PR CI jobs are a subset of Auto CI jobs modulo carve-outs
### Background
Currently, it is possible for a PR with red PR-only CI to pass Auto CI, then all subsequent PR CI runs will be red until that is fixed, even in completely unrelated PRs. For instance, this happened with PR-CI-only Spellcheck (rust-lang/rust#144183).
See more discussions at [#t-infra > Spellcheck workflow now fails on all PRs (tree bad?)](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Spellcheck.20workflow.20now.20fails.20on.20all.20PRs.20.28tree.20bad.3F.29/with/529769404).
### CI invariant: PR CI jobs are a subset of Auto CI jobs modulo carve-outs
To prevent red PR CI in completely unrelated subsequent PRs and PR CI runs, we need to maintain an invariant that **PR CI jobs are a subset of Auto CI jobs modulo carve-outs**.
This is **not** a "strict" subset relationship: some jobs necessarily have to differ under PR CI and Auto CI environments, at least in the current setup. Still, we can try to enforce a weaker "subset modulo carve-outs" relationship between CI jobs and their corresponding Auto jobs. For instance:
- `x86_64-gnu-tools` will have `auto`-only env vars like `DEPLOY_TOOLSTATES_JSON: toolstates-linux.json`.
- `tidy` will want to `continue_on_error: true` in PR CI to allow for more "useful" compilation errors to also be reported, whereas it should be `continue_on_error: false` in Auto CI to prevent wasting Auto CI resources.
The **carve-outs** are:
1. `env` variables.
2. `continue_on_error`.
We enforce this invariant through `citool`, so only affects job definitions that are handled by `citool`. Notably, this is not sufficient *alone* to address the CI-only Spellcheck issue (rust-lang/rust#144183). To carry out this enforcement, we modify `citool` to auto-register PR jobs as Auto jobs with `continue_on_error` overridden to `false` **unless** there's an overriding Auto job for the PR job of the same name that only differs by the permitted **carve-outs**.
### Addressing the Spellcheck PR-only CI issue
Note that Spellcheck currently does not go through `citool` or `bootstrap`, and is its own GitHub Actions workflow. To actually address the PR-CI-only Spellcheck issue (rust-lang/rust#144183), and carry out the subset-modulo-carve-outs enforcement universally, this PR additionally **removes the current Spellcheck implementation** (a separate GitHub Actions Workflow). That is incompatible with Homu unless we do some hacks in the main CI workflow.
This effectively partially reverts rust-lang/rust#134006 (the separate workflow part, not the tidy extra checks component), but is not prejudice against relanding the `typos`-based spellcheck in another implementation that goes through the usual bootstrap CI workflow so that it does work with Homu. The `typos`-based spellcheck seems to have a good false-positive rate.
Closesrust-lang/rust#144183.
---
r? infra-ci
