…rovement

This reverts commit 3f1ad47.

…onding impls exist

…w the extention of contexts by futures

…y removing a #[cfg(target_has_atomic = ptr)]

…t-lang#96992.

Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>

…ation

This also removes
* impl From<&Context> for ContextBuilder
* Context::try_waker()

The from implementation is removed because now that
wakers are always supported, there are less incentives
to override the current context. Before, the incentive
was to add Waker support to a reactor that didn't have
any.

Makes the trait implementation documentation for arrays and slices appear more consistent.

Disable packed/unpacked options for riscv linux/android.
Other riscv targets already only have the off option.

The packed/unpacked options might be supported in the future.
See upstream issue for more details:
llvm/llvm-project#56642

Fixes rust-lang#110224

Co-authored-by: teor <teor@riseup.net>

The Rust LoongArch targets have been using the default LLVM code model
so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak.
As described in the "Code Model" section of LoongArch ELF psABI spec
v20231219 [1], one can only make function calls as far as ±128MiB with
the "normal" code model; this is insufficient for very large software
containing Rust components that needs to be linked into the big text
section, such as Chromium.

Because:

* we do not want to ask users to recompile std if they are to build
  such software,
* objects compiled with larger code models can be linked with those
  with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one
  performance-wise (same data access pattern; each function call
  becomes 2-insn long and indirect, but this may be relaxed back into
  the direct 1-insn form in a future LLVM version), but is able to
  perform function calls within ±128GiB,

it is better to just switch the targets to the "medium" code model,
which is also "medium" in LLVM-speak.

[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models

`std::error::Error` -> Trait Implementations: lifetimes consistency improvement

This cleans up `std::error::Error` trait implementations lifetime inconsistency (`'static` -> `'a`)

**Reasoning:**

Trait implementations for `std::error::Error`, like:
`impl From<&str> for Box<dyn Error + 'static, Global>`
`impl<'a> From<&str> for Box<dyn Error + Sync + Send + 'a, Global>`
use different lifetime annotations misleadingly implying using different life annotations here is a conscious, nonaccidental decision.

[(Related forum discussion here)](https://users.rust-lang.org/t/confusing-std-error-source-code/97011/5?u=wiktor)

PartialEq, PartialOrd: update and synchronize handling of transitive chains

It was brought up in https://internals.rust-lang.org/t/total-equality-relations-as-std-eq-rhs/19232 that we currently have a gap in our `PartialEq` rules, which this PR aims to close:

> For example, with PartialEq's conditions you may have a = b = c = d ≠ a (where a and c are of type A, b and d are of type B).

The second commit fixes rust-lang#87067 by updating PartialOrd to handle the requirements the same way PartialEq does.

make matching on NaN a hard error, and remove the rest of illegal_floating_point_literal_pattern

These arms would never be hit anyway, so the pattern makes little sense. We have had a future-compat lint against float matches in general for a *long* time, so I hope we can get away with immediately making this a hard error.

This is part of implementing rust-lang/rfcs#3535.

Closes rust-lang#41620 by removing the lint.

rust-lang/reference#1456 updates the reference to match.

…ulacrum

Add LocalWaker and ContextBuilder types to core, and LocalWake trait to alloc.

Implementation for  rust-lang#118959.

…r=Mark-Simulacrum

Use `<T, U>` for array/slice equality `impl`s

Makes the trait implementation documentation for arrays and slices appear more consistent.

[Example](https://doc.rust-lang.org/1.75.0/std/primitive.array.html): mixed `A`, `B`, and `U`.
![List of PartialEq implementations for arrays](https://github.com/wackbyte/rust/assets/29505620/823c010e-ee57-4de1-885b-a1cd6dcaf85f)

This change makes them all `U`.

…piler-errors

riscv only supports split_debuginfo=off for now

Disable packed/unpacked options for riscv linux/android. Other riscv targets already only have the off option.

The packed/unpacked options might be supported in the future. See upstream issue for more details:
llvm/llvm-project#56642

Fixes rust-lang#110224

Remove unused struct

Detected by rust-lang#118257

…r,Nilstrieb

target: default to the medium code model on LoongArch targets

The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As [described][1] in the "Code Model" section of LoongArch ELF psABI spec v20231219, one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.

Because:

* we do not want to ask users to recompile std if they are to build such software,
* objects compiled with larger code models can be linked with those with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,

it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.

[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models