Signed-off-by: onur-ozkan <work@onurozkan.dev>

sometimes a safety comment is a prayer.
avoid fuzzy provenance casts after deref.

Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>

This is technically "not necessary", as we will "just" segfault instead
if we e.g. arrive inside the handler fn with the null altstack. However,
it seems incorrect to go about this hoping that segfaulting is okay,
seeing as how our purpose here is to mitigate stack overflow problems.

Make sure NEED_ALTSTACK syncs with PAGE_SIZE when we do.

Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>

Editorialize on the wisdom of this as we do.

Note that current_guard is probably not unsafe for future work.

Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>

Only the last candidate can possibly have more match pairs, so this can be
separate from the main or-candidate postprocessing loop.

When CI rustc is enabled and rustdoc sources are unchanged, we can use
the precompiled rustdoc from the CI rustc's sysroot. This speeds up
bootstrapping quite a lot by avoiding unnecessary rustdoc compilation.

Signed-off-by: onur-ozkan <work@onurozkan.dev>

…Kobzol

 use precompiled rustdoc with CI rustc

When CI rustc is enabled and rustdoc sources are unchanged, we can use the precompiled rustdoc from the CI rustc's sysroot. This speeds up bootstrapping quite a lot by avoiding unnecessary rustdoc compilation.

…illot

Add a hook for `should_codegen_locally`

This PR lifts the module-local function `should_codegen_locally` to `TyCtxt` as a hook.
In addition to monomorphization, this function is used for checking the dependency of `compiler_builtins` on other libraries. Moving this function to the hooks also makes overriding it possible for the tools that use the rustc interface.

…ack-overflow-fn, r=joboet

unix: document unsafety for std `sig{action,altstack}`

I found many surprising elements here while trying to wrap a measly 5 functions with `unsafe`. I would rather not "just" mindlessly wrap this code with `unsafe { }`, so I decided to document it properly.

On Unix, this code covers the "create and setup signal handler" part of the stack overflow code, and serves as the primary safety boundary for the signal handler. It is rarely audited, very gnarly, and worth extra attention. It calls other unsafe functions defined in this module, but "can we correctly map the right memory, or find the right address ranges?" are separate questions, and get increasingly platform-specific. The question here is the more general "are we doing everything in the correct order, and setting up the handler in the correct way?"

As part of this audit, I noticed that we do some peculiar things that we should probably refrain from. However, I avoided making changes that I deemed might have a different final result in Rust programs. I did, however, reorder some events so that the signal handler is installed _after_ we install the alternate stack. We do not run much code between these events, but it is probably best if the timespan between the handler being available and the new stack being installed is 0 nanoseconds.

…or-kmc-solid, r=Amanieu

kmc-solid: `#![forbid(unsafe_op_in_unsafe_fn)]`

The path logic _should_ handle the forbiddance in the itron sources correctly, despite them being an "out-of-line" module.

match lowering: Split `finalize_or_candidate` into more coherent methods

I noticed that `finalize_or_candidate` was responsible for several different postprocessing tasks, making it difficult to understand.

This PR aims to clean up some of the confusion by:
- Extracting `remove_never_subcandidates` from `merge_trivial_subcandidates`
- Extracting `test_remaining_match_pairs_after_or` from `finalize_or_candidate`
- Taking what remains of `finalize_or_candidate`, and inlining it into its caller

---
Reviewing individual commits and ignoring whitespace is recommended.

Most of the large-looking changes are just moving existing code around, mostly unaltered.

r? ``@Nadrieril``

…thercote

run_make_support: skip rustfmt for lib.rs

To avoid them getting reordered once rust-lang#125443 goes through.

r? ``@nnethercote`` (since you were working on this)