Unify terminology used in unwind action and terminator, and reflect
the fact that a nounwind panic is triggered instead of an immediate
abort is triggered for this terminator.
Rollup of 7 pull requests
Successful merges:
- #109909 (Deny `use`ing tool paths)
- #109921 (Don't ICE when encountering `dyn*` in statics or consts)
- #109922 (Disable `has_thread_local` on OpenHarmony)
- #109926 (write threads info into log only when debugging)
- #109968 (Add regression test for #80409)
- #109969 (Add regression test for #86351)
- #109973 (rustdoc: Improve logo display very small screen)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
write threads info into log only when debugging
The current tracing log will unconditionally write thread information during parallel compilation, which sometimes confuses some normal output log information
This fixes the UI test failure of:
```
[ui] tests/ui/consts/const_in_pattern/issue-73431.rs
```
Updates #75760
Disable `has_thread_local` on OpenHarmony
OpenHarmony uses emulated TLS, which doesn't link properly when using thread-local variables across crate boundaries with `-C prefer-dynamic`. This PR makes thread_local! use pthreads directly instead.
Don't ICE when encountering `dyn*` in statics or consts
Since we have properly implemented `dyn*` support in CTFE (#107728), let's not ICE here anymore.
Fixes#105777
r? `@eholk`
Use SipHash-1-3 instead of SipHash-2-4 for StableHasher
Noticed this, and it seems easy and likely a perf win. IIUC we don't need DDOS resistance (just collision) so we ideally would have an even faster hash, but it's hard to beat this SipHash impl here, since it's been so highly tuned for the interface.
It wouldn't surprise me if there's some subtle reason changing this sucks, as it's so obvious it seems likely to have been done. Still, SipHash-1-3 seems to still have the guarantees StableHasher should need (and seemingly more), and is clearly less work. So it's worth a shot.
Not fully tested locally.
Validate `ignore` and `only` compiletest directive, and add human-readable ignore reasons
This PR adds strict validation for the `ignore` and `only` compiletest directives, failing if an unknown value is provided to them. Doing so uncovered 79 tests in `tests/ui` that had invalid directives, so this PR also fixes them.
Finally, this PR adds human-readable ignore reasons when tests are ignored due to `ignore` or `only` directives, like *"only executed when the architecture is aarch64"* or *"ignored when the operative system is windows"*. This was the original reason why I started working on this PR and #108659, as we need both of them for Ferrocene.
The PR is a draft because the code is extremely inefficient: it calls `rustc --print=cfg --target $target` for every rustc target (to gather the list of allowed ignore values), which on my system takes between 4s and 5s, and performs a lot of allocations of constant values. I'll fix both of them in the coming days.
r? `@ehuss`
Turns out
- `owning_ref` is unsound due to `Box` aliasing stuff
- `rustc` doesn't need 99% of the `owning_ref` API
- `rustc` can use a far simpler abstraction that is `OwnedSlice`
Tweak debug outputs to make debugging new solver easier
1. Move the fields that are "most important" (I know this is subjective) to the beginning of the structs.
For goals, I typically care more about the predicate than the param-env (which is significantly longer in debug output).
For canonicalized things, I typically care more about what is *being* canonicalized.
For a canonical response, I typically care about the response -- or at least, it's typically useful to put it first since it's short and affects the whether the solver recurses or not...
2. Add some more debug and instrument calls to functions to add more structure to tracing lines.
r? `@oli-obk` or `@BoxyUwU` (since I think `@lcnr` is on holiday)
Avoid a few locks
We can use atomics or datastructures tuned for specific access patterns instead of locks. This may be an improvement for parallel rustc, but it's mostly a cleanup making various datastructures only usable in the way they are used right now (append data, never mutate), instead of having a general purpose lock.
