This file tests for UB in `reduce_add`, but those are reimplemented by explicitly using the associativity specified by Intel

…` and aren't accidentally usable on completely unrelated HIR nodes

Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>

…eyouxu

Migrate `reproducible-build-2` and `stable-symbol-names` `run-make` tests to rmake

Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Needs try-jobs.

try-job: x86_64-msvc
try-job: armhf-gnu
try-job: test-various
try-job: aarch64-apple
try-job: i686-msvc
try-job: x86_64-mingw

…-blocks, r=compiler-errors

Stabilize unsafe extern blocks (RFC 3484)

# Stabilization report

## Summary

This is a tracking issue for the RFC 3484: Unsafe Extern Blocks

We are stabilizing `#![feature(unsafe_extern_blocks)]`, as described in [Unsafe Extern Blocks RFC 3484](rust-lang/rfcs#3484). This feature makes explicit that declaring an extern block is unsafe. Starting in Rust 2024, all extern blocks must be marked as unsafe. In all editions, items within unsafe extern blocks may be marked as safe to use.

RFC: rust-lang/rfcs#3484
Tracking issue: rust-lang#123743

## What is stabilized

### Summary of stabilization

We now need extern blocks to be marked as unsafe and items inside can also have safety modifiers (unsafe or safe), by default items with no modifiers are unsafe to offer easy migration without surprising results.

```rust
unsafe extern {
    // sqrt (from libm) may be called with any `f64`
    pub safe fn sqrt(x: f64) -> f64;

    // strlen (from libc) requires a valid pointer,
    // so we mark it as being an unsafe fn
    pub unsafe fn strlen(p: *const c_char) -> usize;

    // this function doesn't say safe or unsafe, so it defaults to unsafe
    pub fn free(p: *mut core::ffi::c_void);

    pub safe static IMPORTANT_BYTES: [u8; 256];

    pub safe static LINES: SyncUnsafeCell<i32>;
}
```

## Tests

The relevant tests are in `tests/ui/rust-2024/unsafe-extern-blocks`.

## History

- rust-lang#124482
- rust-lang#124455
- rust-lang#125077
- rust-lang#125522
- rust-lang#126738
- rust-lang#126749
- rust-lang#126755
- rust-lang#126757
- rust-lang#126758
- rust-lang#126756
- rust-lang#126973
- rust-lang#127535
- rust-lang/rustfmt#6204

## Unresolved questions

I am not aware of any unresolved questions.

Update the stdarch submodule

cc `@tgross35` `@Amanieu`
r? `@tgross35`

try-job: x86_64-rust-for-linux
try-job: test-various
try-job: dist-x86_64-linux

Implement `UncheckedIterator` directly for `RepeatN`

This just pulls the code out of `next` into `next_unchecked`, rather than making the `Some` and `unwrap_unchecked`ing it.

And while I was touching it, I added a codegen test that `array::repeat` for something that's just `Clone`, not `Copy`, still ends up optimizing to the same thing as `[x; n]`: <https://rust.godbolt.org/z/YY3a5ajMW>.

Assert that all attributes are actually checked via `CheckAttrVisitor` and aren't accidentally usable on completely unrelated HIR nodes

`@oli-obk's` rust-lang#128444 with unreachable case removed to avoid that PR bitrotting away.
Based on rust-lang#128402.

This PR will make adding a new attribute ICE on any use of that attribute unless it gets a handler added in `rustc_passes::CheckAttrVisitor`.

r? `@nnethercote` (since you were the reviewer of the original PR)

Update run-make/used to use `any_symbol_contains`

This makes it so we don't need `nm` or `llvm-nm`.

I also tested that `BAR` is removed. I'm not sure if this is wanted though.