Don't ICE when no bound vars found while doing closure hir type check
The problem was that we were not visiting the const generic default argument in a bound where predicate when the HIR gets traversed in hir_analysis -> collect -> resolve_bound_vars.
Fixes [112574](https://github.com/rust-lang/rust/issues/112574)
Update crates for better MIPS R6 support
Update crates to remove dependency on old versions of rustix and linux-raw-sys. Update libc, rustix, and linux-raw-sys to enhance support for MIPS R6 introduced by #112374
Commands that do the update:
```shell
cargo +nightly update tempfile clap
cargo +nightly update linux-raw-sys rustix
```
Move `llvm.x86.*` shims into `shims::x86` and implement `_addcarry_u32` and `_subborrow_u{32,64}`
This PR moves all `llvm.x86.*` shims into `shims::x86` and adds `llvm.x86.addcarry.32`, `llvm.x86.subborrow.32` and `llvm.x86.subborrow.64`.
Additionally, it fixes the input carry semantics of `llvm.x86.addcarry.32`. The input carry is an 8-bit value that is interpreted as 1 when it is non-zero.
https://www.intel.com/content/www/us/en/docs/cpp-compiler/developer-guide-reference/2021-8/addcarry-u32-addcarry-u64.html
Add assembly test to make sure that inlining works as expected when closures inherit target features
Closes https://github.com/rust-lang/rust/issues/108338 (the added test proves that it is working correctly)
Clarify example in `Pin::new_unchecked` docs
This example in the docs of `Pin::new_unchecked` puzzled me for a relatively long time. Now I understand that it comes down to the difference between dropping the `Pin` vs dropping the pinned value.
I have extended the explanation to highlight this difference. In my opinion it is clearer now, and I hope it helps others understand `Pin` better.
fix OS-specific I/O safety docs since the io_safety feature is stable
Looks like this text was forgotten to be updated when `io_safety` got stabilized: it still says "once the io_safety feature is stable".
Also adjust the wording a bit for how these docs relate to the general concept of I/O safety.
prevent ice when threshold is 0 and enum has no variants
changelog: [`enum_variant_names`]: prevent ice when threshold is 0 and enum has no variants
r? `@y21`
Fixes the same ice issue raised during review of https://github.com/rust-lang/rust-clippy/pull/11496
Add OwnedTargetMachine to manage llvm:TargetMachine
LLVMRustDisposeTargetMachine taking a &mut could be undefined behaviour.
Wrapping it with a struct and using pointers instead avoids this problem.
In addition the TargetMachine is now automatically freed via the Wrappers drop impl. This should fix some memory leaks when
create_informational_target_machine was used, e.g. 327e6cf55c/compiler/rustc_codegen_llvm/src/llvm_util.rs (L291-L314)
r? `@Nilstrieb`
