Add new `{x86_64,i686}-win7-windows-gnu` targets

These are in symmetry with `{x86_64,i686}-win7-windows-msvc`.

> ## Tier 3 target policy
>
> At this tier, the Rust project provides no official support for a target, so we
> place minimal requirements on the introduction of targets.
>
> A proposed new tier 3 target must be reviewed and approved by a member of the
> compiler team based on these requirements. The reviewer may choose to gauge
> broader compiler team consensus via a [Major Change Proposal (MCP)][https://forge.rust-lang.org/compiler/mcp.html].
>
> A proposed target or target-specific patch that substantially changes code
> shared with other targets (not just target-specific code) must be reviewed and
> approved by the appropriate team for that shared code before acceptance.
>
> - A tier 3 target must have a designated developer or developers (the "target
>   maintainers") on record to be CCed when issues arise regarding the target.
>   (The mechanism to track and CC such developers may evolve over time.)

This is me, `@tbu-` on github.

> - Targets must use naming consistent with any existing targets; for instance, a
>   target for the same CPU or OS as an existing Rust target should use the same
>   name for that CPU or OS. Targets should normally use the same names and
>   naming conventions as used elsewhere in the broader ecosystem beyond Rust
>   (such as in other toolchains), unless they have a very good reason to
>   diverge. Changing the name of a target can be highly disruptive, especially
>   once the target reaches a higher tier, so getting the name right is important
>   even for a tier 3 target.
>   - Target names should not introduce undue confusion or ambiguity unless
>     absolutely necessary to maintain ecosystem compatibility. For example, if
>     the name of the target makes people extremely likely to form incorrect
>     beliefs about what it targets, the name should be changed or augmented to
>     disambiguate it.
>   - If possible, use only letters, numbers, dashes and underscores for the name.
>     Periods (`.`) are known to cause issues in Cargo.

Consistent with `{x86_64,i686}-win7-windows-msvc`, see also rust-lang#118150.

> - Tier 3 targets may have unusual requirements to build or use, but must not
>   create legal issues or impose onerous legal terms for the Rust project or for
>   Rust developers or users.
>   - The target must not introduce license incompatibilities.
>   - Anything added to the Rust repository must be under the standard Rust
>     license (`MIT OR Apache-2.0`).
>   - The target must not cause the Rust tools or libraries built for any other
>     host (even when supporting cross-compilation to the target) to depend
>     on any new dependency less permissive than the Rust licensing policy. This
>     applies whether the dependency is a Rust crate that would require adding
>     new license exceptions (as specified by the `tidy` tool in the
>     rust-lang/rust repository), or whether the dependency is a native library
>     or binary. In other words, the introduction of the target must not cause a
>     user installing or running a version of Rust or the Rust tools to be
>     subject to any new license requirements.
>   - Compiling, linking, and emitting functional binaries, libraries, or other
>     code for the target (whether hosted on the target itself or cross-compiling
>     from another target) must not depend on proprietary (non-FOSS) libraries.
>     Host tools built for the target itself may depend on the ordinary runtime
>     libraries supplied by the platform and commonly used by other applications
>     built for the target, but those libraries must not be required for code
>     generation for the target; cross-compilation to the target must not require
>     such libraries at all. For instance, `rustc` built for the target may
>     depend on a common proprietary C runtime library or console output library,
>     but must not depend on a proprietary code generation library or code
>     optimization library. Rust's license permits such combinations, but the
>     Rust project has no interest in maintaining such combinations within the
>     scope of Rust itself, even at tier 3.
>   - "onerous" here is an intentionally subjective term. At a minimum, "onerous"
>     legal/licensing terms include but are *not* limited to: non-disclosure
>     requirements, non-compete requirements, contributor license agreements
>     (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
>     requirements conditional on the employer or employment of any particular
>     Rust developers, revocable terms, any requirements that create liability
>     for the Rust project or its developers or users, or any requirements that
>     adversely affect the livelihood or prospects of the Rust project or its
>     developers or users.

AFAICT, it's the same legal situation as the tier 1 `{x86_64,i686}-pc-windows-gnu`.

> - Neither this policy nor any decisions made regarding targets shall create any
>   binding agreement or estoppel by any party. If any member of an approving
>   Rust team serves as one of the maintainers of a target, or has any legal or
>   employment requirement (explicit or implicit) that might affect their
>   decisions regarding a target, they must recuse themselves from any approval
>   decisions regarding the target's tier status, though they may otherwise
>   participate in discussions.
>   - This requirement does not prevent part or all of this policy from being
>     cited in an explicit contract or work agreement (e.g. to implement or
>     maintain support for a target). This requirement exists to ensure that a
>     developer or team responsible for reviewing and approving a target does not
>     face any legal threats or obligations that would prevent them from freely
>     exercising their judgment in such approval, even if such judgment involves
>     subjective matters or goes beyond the letter of these requirements.

Understood.

> - Tier 3 targets should attempt to implement as much of the standard libraries
>   as possible and appropriate (`core` for most targets, `alloc` for targets
>   that can support dynamic memory allocation, `std` for targets with an
>   operating system or equivalent layer of system-provided functionality), but
>   may leave some code unimplemented (either unavailable or stubbed out as
>   appropriate), whether because the target makes it impossible to implement or
>   challenging to implement. The authors of pull requests are not obligated to
>   avoid calling any portions of the standard library on the basis of a tier 3
>   target not implementing those portions.

This target supports the whole libstd surface, since it's essentially reusing all of the x86_64-pc-windows-gnu target. Understood.

> - The target must provide documentation for the Rust community explaining how
>   to build for the target, using cross-compilation if possible. If the target
>   supports running binaries, or running tests (even if they do not pass), the
>   documentation must explain how to run such binaries or tests for the target,
>   using emulation if possible or dedicated hardware if necessary.

I tried to write some documentation on that.

> - Tier 3 targets must not impose burden on the authors of pull requests, or
>   other developers in the community, to maintain the target. In particular,
>   do not post comments (automated or manual) on a PR that derail or suggest a
>   block on the PR based on a tier 3 target. Do not send automated messages or
>   notifications (via any medium, including via ``@`)` to a PR author or others
>   involved with a PR regarding a tier 3 target, unless they have opted into
>   such messages.
>   - Backlinks such as those generated by the issue/PR tracker when linking to
>     an issue or PR are not considered a violation of this policy, within
>     reason. However, such messages (even on a separate repository) must not
>     generate notifications to anyone involved with a PR who has not requested
>     such notifications.

Understood.

> - Patches adding or updating tier 3 targets must not break any existing tier 2
>   or tier 1 target, and must not knowingly break another tier 3 target without
>   approval of either the compiler team or the maintainers of the other tier 3
>   target.
>   - In particular, this may come up when working on closely related targets,
>     such as variations of the same architecture with different features. Avoid
>     introducing unconditional uses of features that another variation of the
>     target may not have; use conditional compilation or runtime detection, as
>     appropriate, to let each target run code supported by that target.
> - Tier 3 targets must be able to produce assembly using at least one of
>   rustc's supported backends from any host target. (Having support in a fork
>   of the backend is not sufficient, it must be upstream.)

Understood.

> If a tier 3 target stops meeting these requirements, or the target maintainers
> no longer have interest or time, or the target shows no signs of activity and
> has not built for some time, or removing the target would improve the quality
> of the Rust codebase, we may post a PR to remove it; any such PR will be CCed
> to the target maintainers (and potentially other people who have previously
> worked on the target), to check potential interest in improving the situation.
>

Understood.

r? compiler-team

…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#128110 (Suggest Replacing Comma with Semicolon in Incorrect Repeat Expressions)
 - rust-lang#134609 (Add new `{x86_64,i686}-win7-windows-gnu` targets)
 - rust-lang#134875 (Implement `const Destruct` in old solver)
 - rust-lang#135221 (Include rustc and rustdoc book in replace-version-placeholder)
 - rust-lang#135231 (bootstrap: Add more comments to some of the test steps)
 - rust-lang#135256 (Move `mod cargo`  below the import statements)

Failed merges:

 - rust-lang#135195 (Make `lit_to_mir_constant` and `lit_to_const` infallible)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#134609 - tbu-:pr_win7_gnu, r=davidtwco

Add new `{x86_64,i686}-win7-windows-gnu` targets

These are in symmetry with `{x86_64,i686}-win7-windows-msvc`.

> ## Tier 3 target policy
>
> At this tier, the Rust project provides no official support for a target, so we
> place minimal requirements on the introduction of targets.
>
> A proposed new tier 3 target must be reviewed and approved by a member of the
> compiler team based on these requirements. The reviewer may choose to gauge
> broader compiler team consensus via a [Major Change Proposal (MCP)][https://forge.rust-lang.org/compiler/mcp.html].
>
> A proposed target or target-specific patch that substantially changes code
> shared with other targets (not just target-specific code) must be reviewed and
> approved by the appropriate team for that shared code before acceptance.
>
> - A tier 3 target must have a designated developer or developers (the "target
>   maintainers") on record to be CCed when issues arise regarding the target.
>   (The mechanism to track and CC such developers may evolve over time.)

This is me, `@tbu-` on github.

> - Targets must use naming consistent with any existing targets; for instance, a
>   target for the same CPU or OS as an existing Rust target should use the same
>   name for that CPU or OS. Targets should normally use the same names and
>   naming conventions as used elsewhere in the broader ecosystem beyond Rust
>   (such as in other toolchains), unless they have a very good reason to
>   diverge. Changing the name of a target can be highly disruptive, especially
>   once the target reaches a higher tier, so getting the name right is important
>   even for a tier 3 target.
>   - Target names should not introduce undue confusion or ambiguity unless
>     absolutely necessary to maintain ecosystem compatibility. For example, if
>     the name of the target makes people extremely likely to form incorrect
>     beliefs about what it targets, the name should be changed or augmented to
>     disambiguate it.
>   - If possible, use only letters, numbers, dashes and underscores for the name.
>     Periods (`.`) are known to cause issues in Cargo.

Consistent with `{x86_64,i686}-win7-windows-msvc`, see also rust-lang#118150.

> - Tier 3 targets may have unusual requirements to build or use, but must not
>   create legal issues or impose onerous legal terms for the Rust project or for
>   Rust developers or users.
>   - The target must not introduce license incompatibilities.
>   - Anything added to the Rust repository must be under the standard Rust
>     license (`MIT OR Apache-2.0`).
>   - The target must not cause the Rust tools or libraries built for any other
>     host (even when supporting cross-compilation to the target) to depend
>     on any new dependency less permissive than the Rust licensing policy. This
>     applies whether the dependency is a Rust crate that would require adding
>     new license exceptions (as specified by the `tidy` tool in the
>     rust-lang/rust repository), or whether the dependency is a native library
>     or binary. In other words, the introduction of the target must not cause a
>     user installing or running a version of Rust or the Rust tools to be
>     subject to any new license requirements.
>   - Compiling, linking, and emitting functional binaries, libraries, or other
>     code for the target (whether hosted on the target itself or cross-compiling
>     from another target) must not depend on proprietary (non-FOSS) libraries.
>     Host tools built for the target itself may depend on the ordinary runtime
>     libraries supplied by the platform and commonly used by other applications
>     built for the target, but those libraries must not be required for code
>     generation for the target; cross-compilation to the target must not require
>     such libraries at all. For instance, `rustc` built for the target may
>     depend on a common proprietary C runtime library or console output library,
>     but must not depend on a proprietary code generation library or code
>     optimization library. Rust's license permits such combinations, but the
>     Rust project has no interest in maintaining such combinations within the
>     scope of Rust itself, even at tier 3.
>   - "onerous" here is an intentionally subjective term. At a minimum, "onerous"
>     legal/licensing terms include but are *not* limited to: non-disclosure
>     requirements, non-compete requirements, contributor license agreements
>     (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
>     requirements conditional on the employer or employment of any particular
>     Rust developers, revocable terms, any requirements that create liability
>     for the Rust project or its developers or users, or any requirements that
>     adversely affect the livelihood or prospects of the Rust project or its
>     developers or users.

AFAICT, it's the same legal situation as the tier 1 `{x86_64,i686}-pc-windows-gnu`.

> - Neither this policy nor any decisions made regarding targets shall create any
>   binding agreement or estoppel by any party. If any member of an approving
>   Rust team serves as one of the maintainers of a target, or has any legal or
>   employment requirement (explicit or implicit) that might affect their
>   decisions regarding a target, they must recuse themselves from any approval
>   decisions regarding the target's tier status, though they may otherwise
>   participate in discussions.
>   - This requirement does not prevent part or all of this policy from being
>     cited in an explicit contract or work agreement (e.g. to implement or
>     maintain support for a target). This requirement exists to ensure that a
>     developer or team responsible for reviewing and approving a target does not
>     face any legal threats or obligations that would prevent them from freely
>     exercising their judgment in such approval, even if such judgment involves
>     subjective matters or goes beyond the letter of these requirements.

Understood.

> - Tier 3 targets should attempt to implement as much of the standard libraries
>   as possible and appropriate (`core` for most targets, `alloc` for targets
>   that can support dynamic memory allocation, `std` for targets with an
>   operating system or equivalent layer of system-provided functionality), but
>   may leave some code unimplemented (either unavailable or stubbed out as
>   appropriate), whether because the target makes it impossible to implement or
>   challenging to implement. The authors of pull requests are not obligated to
>   avoid calling any portions of the standard library on the basis of a tier 3
>   target not implementing those portions.

This target supports the whole libstd surface, since it's essentially reusing all of the x86_64-pc-windows-gnu target. Understood.

> - The target must provide documentation for the Rust community explaining how
>   to build for the target, using cross-compilation if possible. If the target
>   supports running binaries, or running tests (even if they do not pass), the
>   documentation must explain how to run such binaries or tests for the target,
>   using emulation if possible or dedicated hardware if necessary.

I tried to write some documentation on that.

> - Tier 3 targets must not impose burden on the authors of pull requests, or
>   other developers in the community, to maintain the target. In particular,
>   do not post comments (automated or manual) on a PR that derail or suggest a
>   block on the PR based on a tier 3 target. Do not send automated messages or
>   notifications (via any medium, including via ``@`)` to a PR author or others
>   involved with a PR regarding a tier 3 target, unless they have opted into
>   such messages.
>   - Backlinks such as those generated by the issue/PR tracker when linking to
>     an issue or PR are not considered a violation of this policy, within
>     reason. However, such messages (even on a separate repository) must not
>     generate notifications to anyone involved with a PR who has not requested
>     such notifications.

Understood.

> - Patches adding or updating tier 3 targets must not break any existing tier 2
>   or tier 1 target, and must not knowingly break another tier 3 target without
>   approval of either the compiler team or the maintainers of the other tier 3
>   target.
>   - In particular, this may come up when working on closely related targets,
>     such as variations of the same architecture with different features. Avoid
>     introducing unconditional uses of features that another variation of the
>     target may not have; use conditional compilation or runtime detection, as
>     appropriate, to let each target run code supported by that target.
> - Tier 3 targets must be able to produce assembly using at least one of
>   rustc's supported backends from any host target. (Having support in a fork
>   of the backend is not sufficient, it must be upstream.)

Understood.

> If a tier 3 target stops meeting these requirements, or the target maintainers
> no longer have interest or time, or the target shows no signs of activity and
> has not built for some time, or removing the target would improve the quality
> of the Rust codebase, we may post a PR to remove it; any such PR will be CCed
> to the target maintainers (and potentially other people who have previously
> worked on the target), to check potential interest in improving the situation.
>

Understood.

r? compiler-team

Upstream changes relative to 1.85.1:

Version 1.86.0 (2025-04-03)
==========================

Language
--------
- [Stabilize upcasting trait objects to supertraits.]
  (rust-lang/rust#134367)
- [Allow safe functions to be marked with the `#[target_feature]` attribute.]
  (rust-lang/rust#134090)
- [The `missing_abi` lint now warns-by-default.]
  (rust-lang/rust#132397)
- Rust now lints about double negations, to catch cases that might
  have intended to be a prefix decrement operator (`--x`) as written
  in other languages. This was previously a clippy lint,
  `clippy::double_neg`, and is [now available directly in Rust as
  `double_negations`.]
  (rust-lang/rust#126604)
- [More pointers are now detected as definitely not-null based on
  their alignment in const eval.]
  (rust-lang/rust#133700)
- [Empty `repr()` attribute applied to invalid items are now
  correctly rejected.]
  (rust-lang/rust#133925)
- [Inner attributes `#![test]` and `#![rustfmt::skip]` are no longer
  accepted in more places than intended.]
  (rust-lang/rust#134276)

Compiler
--------
- [Debug-assert that raw pointers are non-null on access.]
  (rust-lang/rust#134424)
- [Change `-O` to mean `-C opt-level=3` instead of `-C opt-level=2`
  to match Cargo's defaults.]
  (rust-lang/rust#135439)
- [Fix emission of `overflowing_literals` under certain macro environments.]
  (rust-lang/rust#136393)

Platform Support
----------------
- [Replace `i686-unknown-redox` target with `i586-unknown-redox`.]
  (rust-lang/rust#136698)
- [Increase baseline CPU of `i686-unknown-hurd-gnu` to Pentium 4.]
  (rust-lang/rust#136700)
- New tier 3 targets:
  - [`{aarch64-unknown,x86_64-pc}-nto-qnx710_iosock`]
    (rust-lang/rust#133631).
    For supporting Neutrino QNX 7.1 with `io-socket` network stack.
  - [`{aarch64-unknown,x86_64-pc}-nto-qnx800`]
    (rust-lang/rust#133631).
    For supporting Neutrino QNX 8.0 (`no_std`-only).
  - [`{x86_64,i686}-win7-windows-gnu`]
    (rust-lang/rust#134609).
    Intended for backwards compatibility with Windows 7.
    `{x86_64,i686}-win7-windows-msvc` are the Windows MSVC counterparts
    that already exist as Tier 3 targets.
  - [`amdgcn-amd-amdhsa`](rust-lang/rust#134740).
  - [`x86_64-pc-cygwin`](rust-lang/rust#134999).
  - [`{mips,mipsel}-mti-none-elf`]
    (rust-lang/rust#135074).
    Initial bare-metal support.
  - [`m68k-unknown-none-elf`](rust-lang/rust#135085).
  - [`armv7a-nuttx-{eabi,eabihf}`, `aarch64-unknown-nuttx`, and
    `thumbv7a-nuttx-{eabi,eabihf}`]
    (rust-lang/rust#135757).

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------
- The type of `FromBytesWithNulError` in `CStr::from_bytes_with_nul(bytes:
  &[u8]) -> Result<&Self, FromBytesWithNulError>` was [changed from
  an opaque struct to an enum]
  (rust-lang/rust#134143), allowing users
  to examine why the conversion failed.
- [Remove `RustcDecodable` and `RustcEncodable`.]
  (rust-lang/rust#134272)
- [Deprecate libtest's `--logfile` option.]
  (rust-lang/rust#134283)
- [On recent versions of Windows, `std::fs::remove_file` will now
  remove read-only files.]
  (rust-lang/rust#134679)

Stabilized APIs
---------------

- [`{float}::next_down`]
  (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.next_down)
- [`{float}::next_up`]
  (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.next_up)
- [`<[_]>::get_disjoint_mut`]
  (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.get_disjoint_mut)
- [`<[_]>::get_disjoint_unchecked_mut`]
  (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.get_disjoint_unchecked_mut)
- [`slice::GetDisjointMutError`]
  (https://doc.rust-lang.org/stable/std/slice/enum.GetDisjointMutError.html)
- [`HashMap::get_disjoint_mut`]
  (https://doc.rust-lang.org/std/collections/hash_map/struct.HashMap.html#method.get_disjoint_mut)
- [`HashMap::get_disjoint_unchecked_mut`]
  (https://doc.rust-lang.org/std/collections/hash_map/struct.HashMap.html#method.get_disjoint_unchecked_mut)
- [`NonZero::count_ones`]
  (https://doc.rust-lang.org/stable/std/num/struct.NonZero.html#method.count_ones)
- [`Vec::pop_if`]
  (https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop_if)
- [`sync::Once::wait`]
  (https://doc.rust-lang.org/stable/std/sync/struct.Once.html#method.wait)
- [`sync::Once::wait_force`]
  (https://doc.rust-lang.org/stable/std/sync/struct.Once.html#method.wait_force)
- [`sync::OnceLock::wait`]
  (https://doc.rust-lang.org/stable/std/sync/struct.OnceLock.html#method.wait)

These APIs are now stable in const contexts:

- [`hint::black_box`]
  (https://doc.rust-lang.org/stable/std/hint/fn.black_box.html)
- [`io::Cursor::get_mut`]
  (https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#method.get_mut)
- [`io::Cursor::set_position`]
  (https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#method.set_position)
- [`str::is_char_boundary`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.is_char_boundary)
- [`str::split_at`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at)
- [`str::split_at_checked`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at_checked)
- [`str::split_at_mut`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at_mut)
- [`str::split_at_mut_checked`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at_mut_checked)

Cargo
-----
- [When merging, replace rather than combine configuration keys
  that refer to a program path and its arguments.]
  (rust-lang/cargo#15066)
- [Error if both `--package` and `--workspace` are passed but the
  requested package is missing.]
  (rust-lang/cargo#15071) This was previously
  silently ignored, which was considered a bug since missing packages
  should be reported.
- [Deprecate the token argument in `cargo login` to avoid shell history leaks.]
  (rust-lang/cargo#15057)
- [Simplify the implementation of `SourceID` comparisons.]
  (rust-lang/cargo#14980) This may
  potentially change behavior if the canonicalized URL compares
  differently in alternative registries.

Rustdoc
-----
- [Add a sans-serif font setting.]
  (rust-lang/rust#133636)

Compatibility Notes
-------------------
- [The `wasm_c_abi` future compatibility warning is now a hard error.]
  (rust-lang/rust#133951)
  Users of `wasm-bindgen` should upgrade to at least version 0.2.89,
  otherwise compilation will fail.
- [Remove long-deprecated no-op attributes `#![no_start]` and `#![crate_id]`.]
  (rust-lang/rust#134300)
- [The future incompatibility lint `cenum_impl_drop_cast` has been
  made into a hard error.]
  (rust-lang/rust#135964) This means it is
  now an error to cast a field-less enum to an integer if the enum
  implements `Drop`.
- [SSE2 is now required for "i686" 32-bit x86 hard-float targets;
  disabling it causes a warning that will become a hard error
  eventually.]
  (rust-lang/rust#137037) To compile for
  pre-SSE2 32-bit x86, use a "i586" target instead.

Internal Changes
----------------

These changes do not affect any public interfaces of Rust, but they represent
significant improvements to the performance or internals of rustc and related
tools.

- [Build the rustc on AArch64 Linux with ThinLTO + PGO.]
  (rust-lang/rust#133807)
  The ARM 64-bit compiler (AArch64) on Linux is now optimized with
  ThinLTO and PGO, similar to the optimizations we have already
  performed for the x86-64 compiler on Linux. This should make it
  up to 30% faster.

This MR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [rust](https://github.com/rust-lang/rust) | minor | `1.85.1` -> `1.86.0` |

MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot).

**Proposed changes to behavior should be submitted there as MRs.**

---

### Release Notes

<details>
<summary>rust-lang/rust (rust)</summary>

### [`v1.86.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1860-2025-04-03)

[Compare Source](rust-lang/rust@1.85.1...1.86.0)

\==========================

<a id="1.86.0-Language"></a>

## Language

-   [Stabilize upcasting trait objects to supertraits.](rust-lang/rust#134367)
-   [Allow safe functions to be marked with the `#[target_feature]` attribute.](rust-lang/rust#134090)
-   [The `missing_abi` lint now warns-by-default.](rust-lang/rust#132397)
-   Rust now lints about double negations, to catch cases that might have intended to be a prefix decrement operator (`--x`) as written in other languages. This was previously a clippy lint, `clippy::double_neg`, and is [now available directly in Rust as `double_negations`.](rust-lang/rust#126604)
-   [More pointers are now detected as definitely not-null based on their alignment in const eval.](rust-lang/rust#133700)
-   [Empty `repr()` attribute applied to invalid items are now correctly rejected.](rust-lang/rust#133925)
-   [Inner attributes `#![test]` and `#![rustfmt::skip]` are no longer accepted in more places than intended.](rust-lang/rust#134276)

<a id="1.86.0-Compiler"></a>

## Compiler

-   [Debug-assert that raw pointers are non-null on access.](rust-lang/rust#134424)
-   [Change `-O` to mean `-C opt-level=3` instead of `-C opt-level=2` to match Cargo's defaults.](rust-lang/rust#135439)
-   [Fix emission of `overflowing_literals` under certain macro environments.](rust-lang/rust#136393)

<a id="1.86.0-Platform-Support"></a>

## Platform Support

-   [Replace `i686-unknown-redox` target with `i586-unknown-redox`.](rust-lang/rust#136698)
-   [Increase baseline CPU of `i686-unknown-hurd-gnu` to Pentium 4.](rust-lang/rust#136700)
-   New tier 3 targets:
    -   [`{aarch64-unknown,x86_64-pc}-nto-qnx710_iosock`](rust-lang/rust#133631).
        For supporting Neutrino QNX 7.1 with `io-socket` network stack.
    -   [`{aarch64-unknown,x86_64-pc}-nto-qnx800`](rust-lang/rust#133631).
        For supporting Neutrino QNX 8.0 (`no_std`-only).
    -   [`{x86_64,i686}-win7-windows-gnu`](rust-lang/rust#134609).
        Intended for backwards compatibility with Windows 7. `{x86_64,i686}-win7-windows-msvc` are the Windows MSVC counterparts that already exist as Tier 3 targets.
    -   [`amdgcn-amd-amdhsa`](rust-lang/rust#134740).
    -   [`x86_64-pc-cygwin`](rust-lang/rust#134999).
    -   [`{mips,mipsel}-mti-none-elf`](rust-lang/rust#135074).
        Initial bare-metal support.
    -   [`m68k-unknown-none-elf`](rust-lang/rust#135085).
    -   [`armv7a-nuttx-{eabi,eabihf}`, `aarch64-unknown-nuttx`, and `thumbv7a-nuttx-{eabi,eabihf}`](rust-lang/rust#135757).

Refer to Rust's \[platform support page]\[platform-support-doc]
for more information on Rust's tiered platform support.

<a id="1.86.0-Libraries"></a>

## Libraries

-   The type of `FromBytesWithNulError` in `CStr::from_bytes_with_nul(bytes: &[u8]) -> Result<&Self, FromBytesWithNulError>` was [changed from an opaque struct to an enum](rust-lang/rust#134143), allowing users to examine why the conversion failed.
-   [Remove `RustcDecodable` and `RustcEncodable`.](rust-lang/rust#134272)
-   [Deprecate libtest's `--logfile` option.](rust-lang/rust#134283)
-   [On recent versions of Windows, `std::fs::remove_file` will now remove read-only files.](rust-lang/rust#134679)

<a id="1.86.0-Stabilized-APIs"></a>

## Stabilized APIs

-   [`{float}::next_down`](https://doc.rust-lang.org/stable/std/primitive.f64.html#method.next_down)
-   [`{float}::next_up`](https://doc.rust-lang.org/stable/std/primitive.f64.html#method.next_up)
-   [`<[_]>::get_disjoint_mut`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.get_disjoint_mut)
-   [`<[_]>::get_disjoint_unchecked_mut`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.get_disjoint_unchecked_mut)
-   [`slice::GetDisjointMutError`](https://doc.rust-lang.org/stable/std/slice/enum.GetDisjointMutError.html)
-   [`HashMap::get_disjoint_mut`](https://doc.rust-lang.org/std/collections/hash_map/struct.HashMap.html#method.get_disjoint_mut)
-   [`HashMap::get_disjoint_unchecked_mut`](https://doc.rust-lang.org/std/collections/hash_map/struct.HashMap.html#method.get_disjoint_unchecked_mut)
-   [`NonZero::count_ones`](https://doc.rust-lang.org/stable/std/num/struct.NonZero.html#method.count_ones)
-   [`Vec::pop_if`](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop_if)
-   [`sync::Once::wait`](https://doc.rust-lang.org/stable/std/sync/struct.Once.html#method.wait)
-   [`sync::Once::wait_force`](https://doc.rust-lang.org/stable/std/sync/struct.Once.html#method.wait_force)
-   [`sync::OnceLock::wait`](https://doc.rust-lang.org/stable/std/sync/struct.OnceLock.html#method.wait)

These APIs are now stable in const contexts:

-   [`hint::black_box`](https://doc.rust-lang.org/stable/std/hint/fn.black_box.html)
-   [`io::Cursor::get_mut`](https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#method.get_mut)
-   [`io::Cursor::set_position`](https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#method.set_position)
-   [`str::is_char_boundary`](https://doc.rust-lang.org/stable/std/primitive.str.html#method.is_char_boundary)
-   [`str::split_at`](https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at)
-   [`str::split_at_checked`](https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at_checked)
-   [`str::split_at_mut`](https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at_mut)
-   [`str::split_at_mut_checked`](https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at_mut_checked)

<a id="1.86.0-Cargo"></a>

## Cargo

-   [When merging, replace rather than combine configuration keys that refer to a program path and its arguments.](rust-lang/cargo#15066)
-   [Error if both `--package` and `--workspace` are passed but the requested package is missing.](rust-lang/cargo#15071) This was previously silently ignored, which was considered a bug since missing packages should be reported.
-   [Deprecate the token argument in `cargo login` to avoid shell history leaks.](rust-lang/cargo#15057)
-   [Simplify the implementation of `SourceID` comparisons.](rust-lang/cargo#14980) This may potentially change behavior if the canonicalized URL compares differently in alternative registries.

<a id="1.86.0-Rustdoc"></a>

## Rustdoc

-   [Add a sans-serif font setting.](rust-lang/rust#133636)

<a id="1.86.0-Compatibility-Notes"></a>

## Compatibility Notes

-   [The `wasm_c_abi` future compatibility warning is now a hard error.](rust-lang/rust#133951)
    Users of `wasm-bindgen` should upgrade to at least version 0.2.89, otherwise compilation will fail.
-   [Remove long-deprecated no-op attributes `#![no_start]` and `#![crate_id]`.](rust-lang/rust#134300)
-   [The future incompatibility lint `cenum_impl_drop_cast` has been made into a hard error.](rust-lang/rust#135964) This means it is now an error to cast a field-less enum to an integer if the enum implements `Drop`.
-   [SSE2 is now required for "i686" 32-bit x86 hard-float targets; disabling it causes a warning that will become a hard error eventually.](rust-lang/rust#137037)
    To compile for pre-SSE2 32-bit x86, use a "i586" target instead.

<a id="1.86.0-Internal-Changes"></a>

## Internal Changes

These changes do not affect any public interfaces of Rust, but they represent
significant improvements to the performance or internals of rustc and related
tools.

-   [Build the rustc on AArch64 Linux with ThinLTO + PGO.](rust-lang/rust#133807)
    The ARM 64-bit compiler (AArch64) on Linux is now optimized with ThinLTO and PGO, similar to the optimizations we have already performed for the x86-64 compiler on Linux. This should make it up to 30% faster.

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MC4xMS4yIiwidXBkYXRlZEluVmVyIjoiNDAuMTEuMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90Il19-->

Pkgsrc changes:
 * Drop support for building now old 1.76.0 rust natively on 32-bit
   NetBSD arm ports, pushing those to use the rust-bin variant instead.
 * Use of newer GCC on NetBSD/powerpc turned out to not be required,
   given that your kernel and user-land is new enough.  >= 10.0 release?
 * Checksum updates.

Upstream changes:

Version 1.86.0 (2025-04-03)
==========================

Language
--------
- [Stabilize upcasting trait objects to supertraits.]
  (rust-lang/rust#134367)
- [Allow safe functions to be marked with the `#[target_feature]` attribute.]
  (rust-lang/rust#134090)
- [The `missing_abi` lint now warns-by-default.]
  (rust-lang/rust#132397)
- Rust now lints about double negations, to catch cases that might
  have intended to be a prefix decrement operator (`--x`) as written
  in other languages. This was previously a clippy lint,
  `clippy::double_neg`, and is [now available directly in Rust as
  `double_negations`.]
  (rust-lang/rust#126604)
- [More pointers are now detected as definitely not-null based on
  their alignment in const eval.]
  (rust-lang/rust#133700)
- [Empty `repr()` attribute applied to invalid items are now
  correctly rejected.]
  (rust-lang/rust#133925)
- [Inner attributes `#![test]` and `#![rustfmt::skip]` are no longer
  accepted in more places than intended.]
  (rust-lang/rust#134276)

Compiler
--------
- [Debug-assert that raw pointers are non-null on access.]
  (rust-lang/rust#134424)
- [Change `-O` to mean `-C opt-level=3` instead of `-C opt-level=2`
  to match Cargo's defaults.]
  (rust-lang/rust#135439)
- [Fix emission of `overflowing_literals` under certain macro environments.]
  (rust-lang/rust#136393)

Platform Support
----------------
- [Replace `i686-unknown-redox` target with `i586-unknown-redox`.]
  (rust-lang/rust#136698)
- [Increase baseline CPU of `i686-unknown-hurd-gnu` to Pentium 4.]
  (rust-lang/rust#136700)
- New tier 3 targets:
  - [`{aarch64-unknown,x86_64-pc}-nto-qnx710_iosock`]
    (rust-lang/rust#133631).
    For supporting Neutrino QNX 7.1 with `io-socket` network stack.
  - [`{aarch64-unknown,x86_64-pc}-nto-qnx800`]
    (rust-lang/rust#133631).
    For supporting Neutrino QNX 8.0 (`no_std`-only).
  - [`{x86_64,i686}-win7-windows-gnu`]
    (rust-lang/rust#134609).
    Intended for backwards compatibility with Windows 7.
    `{x86_64,i686}-win7-windows-msvc` are the Windows MSVC counterparts
    that already exist as Tier 3 targets.
  - [`amdgcn-amd-amdhsa`](rust-lang/rust#134740).
  - [`x86_64-pc-cygwin`](rust-lang/rust#134999).
  - [`{mips,mipsel}-mti-none-elf`]
    (rust-lang/rust#135074).
    Initial bare-metal support.
  - [`m68k-unknown-none-elf`](rust-lang/rust#135085).
  - [`armv7a-nuttx-{eabi,eabihf}`, `aarch64-unknown-nuttx`, and
    `thumbv7a-nuttx-{eabi,eabihf}`]
    (rust-lang/rust#135757).

Refer to Rust's [platform support page][platform-support-doc]
for more information on Rust's tiered platform support.

Libraries
---------
- The type of `FromBytesWithNulError` in `CStr::from_bytes_with_nul(bytes:
  &[u8]) -> Result<&Self, FromBytesWithNulError>` was [changed from
  an opaque struct to an enum]
  (rust-lang/rust#134143), allowing users
  to examine why the conversion failed.
- [Remove `RustcDecodable` and `RustcEncodable`.]
  (rust-lang/rust#134272)
- [Deprecate libtest's `--logfile` option.]
  (rust-lang/rust#134283)
- [On recent versions of Windows, `std::fs::remove_file` will now
  remove read-only files.]
  (rust-lang/rust#134679)

Stabilized APIs
---------------

- [`{float}::next_down`]
  (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.next_down)
- [`{float}::next_up`]
  (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.next_up)
- [`<[_]>::get_disjoint_mut`]
  (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.get_disjoint_mut)
- [`<[_]>::get_disjoint_unchecked_mut`]
  (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.get_disjoint_unchecked_mut)
- [`slice::GetDisjointMutError`]
  (https://doc.rust-lang.org/stable/std/slice/enum.GetDisjointMutError.html)
- [`HashMap::get_disjoint_mut`]
  (https://doc.rust-lang.org/std/collections/hash_map/struct.HashMap.html#method.get_disjoint_mut)
- [`HashMap::get_disjoint_unchecked_mut`]
  (https://doc.rust-lang.org/std/collections/hash_map/struct.HashMap.html#method.get_disjoint_unchecked_mut)
- [`NonZero::count_ones`]
  (https://doc.rust-lang.org/stable/std/num/struct.NonZero.html#method.count_ones)
- [`Vec::pop_if`]
  (https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pop_if)
- [`sync::Once::wait`]
  (https://doc.rust-lang.org/stable/std/sync/struct.Once.html#method.wait)
- [`sync::Once::wait_force`]
  (https://doc.rust-lang.org/stable/std/sync/struct.Once.html#method.wait_force)
- [`sync::OnceLock::wait`]
  (https://doc.rust-lang.org/stable/std/sync/struct.OnceLock.html#method.wait)

These APIs are now stable in const contexts:

- [`hint::black_box`]
  (https://doc.rust-lang.org/stable/std/hint/fn.black_box.html)
- [`io::Cursor::get_mut`]
  (https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#method.get_mut)
- [`io::Cursor::set_position`]
  (https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#method.set_position)
- [`str::is_char_boundary`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.is_char_boundary)
- [`str::split_at`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at)
- [`str::split_at_checked`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at_checked)
- [`str::split_at_mut`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at_mut)
- [`str::split_at_mut_checked`]
  (https://doc.rust-lang.org/stable/std/primitive.str.html#method.split_at_mut_checked)

Cargo
-----
- [When merging, replace rather than combine configuration keys
  that refer to a program path and its arguments.]
  (rust-lang/cargo#15066)
- [Error if both `--package` and `--workspace` are passed but the
  requested package is missing.]
  (rust-lang/cargo#15071) This was previously
  silently ignored, which was considered a bug since missing packages
  should be reported.
- [Deprecate the token argument in `cargo login` to avoid shell history leaks.]
  (rust-lang/cargo#15057)
- [Simplify the implementation of `SourceID` comparisons.]
  (rust-lang/cargo#14980) This may
  potentially change behavior if the canonicalized URL compares
  differently in alternative registries.

Rustdoc
-----
- [Add a sans-serif font setting.]
  (rust-lang/rust#133636)

Compatibility Notes
-------------------
- [The `wasm_c_abi` future compatibility warning is now a hard error.]
  (rust-lang/rust#133951)
  Users of `wasm-bindgen` should upgrade to at least version 0.2.89,
  otherwise compilation will fail.
- [Remove long-deprecated no-op attributes `#![no_start]` and `#![crate_id]`.]
  (rust-lang/rust#134300)
- [The future incompatibility lint `cenum_impl_drop_cast` has been
  made into a hard error.]
  (rust-lang/rust#135964) This means it is
  now an error to cast a field-less enum to an integer if the enum
  implements `Drop`.
- [SSE2 is now required for "i686" 32-bit x86 hard-float targets;
  disabling it causes a warning that will become a hard error
  eventually.]
  (rust-lang/rust#137037) To compile for
  pre-SSE2 32-bit x86, use a "i586" target instead.

Internal Changes
----------------

These changes do not affect any public interfaces of Rust, but they represent
significant improvements to the performance or internals of rustc and related
tools.

- [Build the rustc on AArch64 Linux with ThinLTO + PGO.]
  (rust-lang/rust#133807)
  The ARM 64-bit compiler (AArch64) on Linux is now optimized with
  ThinLTO and PGO, similar to the optimizations we have already
  performed for the x86-64 compiler on Linux. This should make it
  up to 30% faster.