These were disabled because Apple uses a special ABI for `f16`.
`compiler-builtins` merged a fix for this in [1], which has since
propagated to rust-lang/rust. Enable tests since there should be no
remaining issues on these platforms.

[1]: rust-lang/compiler-builtins#675

Hook up std::net to wasi-libc on wasm32-wasip2 target

One of the improvements of the `wasm32-wasip2` target over `wasm32-wasip1` is better support for networking. Right now, p2 is just re-using the `std::net` implementation from p1. This PR adds a new net module for p2 that makes use of net from `sys_common` and calls wasi-libc functions directly.

There are currently a few limitations:

- Duplicating a socket is not supported by WASIp2 (directly returns an error)
- Peeking is not yet implemented in wasi-libc (we could let wasi-libc handle this, but I opted to directly return an error instead)
- Vectored reads/writes are not supported by WASIp2 (the necessary functions are available in wasi-libc, but they call WASIp1 functions which do not support sockets, so I opted to directly return an error instead)
- Getting/setting `TCP_NODELAY` is faked in wasi-libc (uses the fake implementation instead of returning an error)
- Getting/setting `SO_LINGER` is not supported by WASIp2 (directly returns an error)
- Setting `SO_REUSEADDR` is faked in wasi-libc (since this is done from `sys_common`, the fake implementation is used instead of returning an error)
- Getting/setting `IPV6_V6ONLY` is not supported by WASIp2 and will always be set for IPv6 sockets (since this is done from `sys_common`, wasi-libc will return an error)
- UDP broadcast/multicast is not supported by WASIp2 (since this is configured from `sys_common`, wasi-libc will return appropriate errors)
- The `MSG_NOSIGNAL` send flag is a no-op because there are no signals in WASIp2 (since explicitly setting this flag would require a change to `sys_common` and the result would be exactly the same, I opted to not set it)

Do those decisions make sense?

While working on this PR, I noticed that there is a `std::os::wasi::net::TcpListenerExt` trait that adds a `sock_accept()` method to `std::net::TcpListener`. Now that WASIp2 supports standard accept, would it make sense to remove this?

cc `@alexcrichton`

rustc_target: Add RISC-V atomic-related features

This adds the following three target features to unstable riscv_target_feature.

- `zaamo` (Zaamo Extension 1.0.0): Atomic Memory Operations (`amo*.{w,d}{,.aq,.rl,.aqrl}`)
  ([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L229-L231), [available since LLVM 19](llvm/llvm-project@8be079c))
- `zabha` (Zabha Extension 1.0.0): Byte and Halfword Atomic Memory Operations (`amo*.{b,h}{,.aq,.rl,.aqrl}`)
  ([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L238-L240), [available since LLVM 19](llvm/llvm-project@6b74449))
- `zalrsc` (Zalrsc Extension 1.0.0): Load-Reserved/Store-Conditional Instructions (`lr.{w,d}{,.aq,.rl,.aqrl}` and `sc.{w,d}{,.aq,.rl,.aqrl}`)
  ([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L261-L263), [available since LLVM 19](llvm/llvm-project@8be079c))

(Zacas Extension is not included here because it is still marked as experimental in LLVM 19 llvm/llvm-project@70e7d26 and will become non-experimental in LLVM 20 llvm/llvm-project@614aeda)

`a` implies `zaamo` and `zalrsc`, and `zabha` implies `zaamo`:

- After Zaamo and Zalrsc Extensions are frozen, riscv-isa-manual says "The A extension comprises instructions provided by the Zaamo and Zalrsc extensions" (riscv/riscv-isa-manual@e87412e), and [`a` implies `zaamo` and `zalrsc` in GCC](https://github.com/gcc-mirror/gcc/blob/08693e29ec186fd7941d0b73d4d466388971fe2f/gcc/config/riscv/arch-canonicalize#L44). However, in LLVM, [`a` does not define them as implying `zaamo` and `zalrsc`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L206).
- Zabha and Zaamo are in a similar situation, [riscv-isa-manual](https://github.com/riscv/riscv-isa-manual/blob/main/src/zabha.adoc) says "The Zabha extension depends upon the Zaamo standard extension", and [`zabha` implies `zaamo` in GCC](https://github.com/gcc-mirror/gcc/blob/08693e29ec186fd7941d0b73d4d466388971fe2f/gcc/config/riscv/arch-canonicalize#L45-L46), but [does not in LLVM (but enabling `zabha` without `zaamo` or `a` is not allowed)](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/TargetParser/RISCVISAInfo.cpp#L776-L778).

r? `@Amanieu`

`@rustbot` label +O-riscv +A-target-feature

…, r=Amanieu

Mark some more types as having insignificant dtor

These were caught by rust-lang#129864 (comment), which is implementing a lint for some changes in drop order for temporaries in tail expressions.

Specifically, the destructors of `CString` and the bitpacked repr for `std::io::Error` are insignificant insofar as they don't have side-effects on things like locking or synchronization; they just free memory.

See some discussion on rust-lang#89144 for what makes a drop impl "significant"

Enable `f16` tests on x86 Apple platforms

These were disabled because Apple uses a special ABI for `f16`. `compiler-builtins` merged a fix for this in [1], which has since propagated to rust-lang/rust. Enable tests since there should be no remaining issues on these platforms.

[1]: rust-lang/compiler-builtins#675

try-job: x86_64-apple-1
try-job: x86_64-apple-2

…, r=scottmcm

make ptr metadata functions callable from stable const fn

So far this was done with a bunch of `rustc_allow_const_fn_unstable`. But those should be the exception, not the norm. If we are confident we can expose the ptr metadata APIs *indirectly* in stable const fn, we should just mark them as `rustc_const_stable`. And we better be confident we can do that since it's already been done a while ago. ;)

In particular this marks two intrinsics as const-stable: `aggregate_raw_ptr`, `ptr_metadata`. This should be uncontroversial, they are trivial to implement in the interpreter.
Cc `@rust-lang/wg-const-eval` `@rust-lang/lang`