Do not create a DerefLen place for `Box<[T]>`.

Fixes rust-lang/rust#115789

Document panics on unsigned wrapping_div/rem calls (#116063)

Add missing `# Panics` sections to the `uint_impl!` macro, documenting that the `wrapping_rem/div` calls will panic if passed zero.

Add Minimal Std implementation for UEFI

# Implemented modules:
1. alloc
2. os_str
3. env
4. math

# Related Links
Tracking Issue: rust-lang/rust#100499
API Change Proposal: rust-lang/libs-team#87

# Additional Information
This was originally part of rust-lang/rust#100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR.

The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target.

Signed-off-by: Ayush Singh <[email protected]>

…=cjgillot

Add Zba, Zbb, and Zbs as target features for riscv64-linux-android

This pull request adds the Zba, Zbb, and Zbs target features to the `riscv64-linux-android` target specification.  These features have been enabled and tested internally in Android infrastructure.

Fix debug printing of tuple

Self-explanatory. Didn't create a UI test, but I guess I could -- not sure where debug output shows up in rustc_attrs to make a sufficient test, tho.

…errors

Add regression test for #102467

Fixes #102467.

r? `@compiler-errors`

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.

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.

…ark-Simulacrum

Add assembly test to make sure that inlining works as expected when closures inherit target features

Closes rust-lang/rust#108338 (the added test proves that it is working correctly)

Miri subtree update

r? `@ghost`

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
```

Fix jq in CI

r? `@Mark-Simulacrum`

…ime_binders, r=compiler-errors

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](rust-lang/rust#112574)

… r=Mark-Simulacrum

Avoid overflow in `IoSlice::advance_slices`

Noticed in rust-lang/rust#62726 (comment).

…umeGomez

rustdoc: correctly render the return type of cross-crate async fns

Fixes #115760.

…mjay

Use placeholders to prevent using inferred RPITIT types to imply their own well-formedness

The issue here is that we use the same signature to do RPITIT inference as we do to compute implied bounds. To fix this, when gathering the assumed wf types for the method, we replace all of the infer vars (that will be eventually used to infer RPITIT types) with type placeholders, which imply nothing about lifetime bounds.

This solution kind of sucks, but I'm not certain there's another feasible way to fix this. If anyone has a better solution, I'd be glad to hear it.

My naive first solution was, instead of using placeholders, to replace the signature with the RPITIT projections that it originally started out with. But turns out that we can't just use the unnormalized signature of the trait method in `implied_outlives_bounds` since we normalize during WF computation -- that would cause a query cycle in `collect_return_position_impl_trait_in_trait_tys`.

idk who to request review...
r? `@lcnr` or `@aliemjay` i guess.

Fixes #116060

…, r=compiler-errors

Properly print cstr literals in `proc_macro::Literal::to_string`

Previously we printed the contents of the string, rather than the actual string literal (e.g. `the c string` instead of `c"the c string"`).

Fixes #112820
cc #105723

ConstParamTy: require Eq as supertrait

As discussed with `@BoxyUwu` [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/.60ConstParamTy.60.20and.20.60Eq.60).

We want to say that valtree equality on const generic params agrees with `==`, but that only makes sense if `==` actually exists, hence we should have an appropriate bound. Valtree equality is an equivalence relation, so such a type can always be `Eq` and not just `PartialEq`.

Clippy subtree update

r? `@Manishearth`

Don't use a thread to load the dep graph

This removes the use of a thread to load the dep graph. It's not currently useful as we immediately block on it.

r? `@oli-obk`

lint towards rejecting consts in patterns that do not implement PartialEq

I think we definitely don't want to allow such consts, so even while the general plan around structural matching is up in the air, we can start the process of getting non-PartialEq matches out of the ecosystem.

Use Vec::retain in remove_dead_blocks.

r? `@ghost`

Correct codegen of `ConstValue::Indirect` scalar and scalar pair

This concerns 3 tricky cases with `ConstValue::Indirect`:
- if we want a non-pointer scalar;
- if we have non-zero offset;
- if offset points to uninit memory => generate `poison` instead of an ICE. This case could happen in unreachable code, trying to extract a field from the wrong variant.

Those cases are not currently emitted by the compiler, but are exercised by rust-lang/rust#116012.

Only prevent field projections into opaque types, not types containing opaque types

fixes rust-lang/rust#115778

I did not think that original condition through properly... I'll also need to check the similar check around the other `ProjectionKind::OpaqueCast` creation site (this one is in hir, the other one is in mir), but I'll do that change in another PR that doesn't go into a beta backport.