Only golden arches
A number of tests in the test suite have applied the somewhat comedic practice of ignoring *every* single target architecture that rustc has ever supported. This is silly, when they are clearly tests built around certain assumptions, primarily of the x86-64 architecture, or in one case when they are only relevant for a handful of 32-bit targets. This has even resulted, in one case, in the same architecture being ignored twice!
Document these better, and use a "revision + only-arch" idiom in the test headers to denote the "golden arches" that actually pass these tests.
This function has some shared code for the thin LTO and fat LTO cases,
but those cases have so little in common that it's actually clearer to
treat them fully separately.
PR #112946 tweaked the naming of LLVM threads, but messed things up
slightly, resulting in threads on Windows having names like `optimize
module {} regex.f10ba03eb5ec7975-cgu.0`.
This commit removes the extraneous `{} `.
The main loop has a *very* complex condition, which includes two
mentions of `codegen_state`. The body of the loop then immediately
switches on the `codegen_state`.
I find it easier to understand if it's a `loop` and we check for exit
conditions after switching on `codegen_state`. We end up with a tiny bit
of code duplication, but it's clear that (a) we never exit in the
`Ongoing` case, (b) we exit in the `Completed` state only if several
things are true (and there's interaction with LTO there), and (c) we
exit in the `Aborted` state if a couple of things are true. Also, the
exit conditions are all simple conjunctions.
This loop condition involves `codegen_state`, `work_items`, and
`running_with_own_token`. But the body of the loop cannot modify
`codegen_state`, so repeatedly checking it is unnecessary.
`CodegenContext` is immutable except for the `worker` field - we clone
`CodegenContext` in multiple places, changing the `worker` field each
time. It's simpler to move the `worker` field out of `CodegenContext`.
Because it's usefulness wasn't clear to me, and I initially wondered if
it could be removed. The text is based on the text in #50972, the PR
that added the flag.
It took me some time to understand how the main thread can lend a
jobserver token to an LLVM thread. This commit renames a couple of
things to make it clearer.
- Rename the `LLVMing` variant as `Lending`, because that is a clearer
description of what is happening.
- Rename `running` as `running_with_own_token`, which makes it clearer
that there might be one additional LLVM thread running (with a loaned
token). Also add a comment to its definition.
And rename the `Compiled` variant as `Finished`, because that name makes
it clearer there is nothing left to do, contrasting nicely with the
`Needs*` variants.
Don't install default projection bound for return-position `impl Trait` in trait methods with no body
This ensures that we never try to project to an opaque type in a trait method that has no body to infer its hidden type, which means we never later call `type_of` on that opaque. This is because opaque types try to reveal their hidden type when proving auto traits.
I thought about this a lot, and I think this is a fix that's less likely to introduce other strange downstream ICEs than #113461.
Fixes#113434
r? `@spastorino`
Use `LazyLock` to lazily resolve backtraces
By using TAIT to name the initializing closure, `LazyLock` can be used to replace the current `LazilyResolvedCapture`.
Stabilize const-weak-new
This is a fairly uncontroversial library stabilization, so I'm going ahead and proposing it to ride the trains to stable.
This stabilizes the following APIs, which are defined to be non-allocating constructors.
```rust
// alloc::rc
impl<T> Weak<T> {
pub const fn new() -> Weak<T>;
}
// alloc::sync
impl<T> Weak<T> {
pub const fn new() -> Weak<T>;
}
```
Closes#95091
``@rustbot`` modify labels: +needs-fcp
Bump its stabilization version several times along
the way to accommodate changes in release processes.
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
Co-authored-by: Trevor Gross <t.gross35@gmail.com>
