Draft release notes for 1.86.0

[cuviper]

Update: This has now moved to a pull request -- #139002.

NOTE: We are trying this issue as a new way to work on the draft release notes.
Use the 📝 links to edit those that have a relnotes-tracking-issue,
and they will be updated when we regenerate the notes periodically.

cc @rust-lang/release

---

Version 1.86.0 (2025-04-03)

Language

• 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.
  📝
• The missing_abi lint now warns-by-default.
  📝
• More pointers are now detected as definitely not-null based on their alignment in const eval.
  📝
• Empty repr() attribute applied to invalid items are now correctly rejected.
  📝
• Allow safe functions to be marked with the #[target_feature] attribute.
  📝
• Inner attributes #![test] and #![rustfmt::skip] are no longer accepted in more places than intended.
  📝
• Stabilize the ability to upcast a trait object to one of its supertraits.
  📝

Compiler

• Debug-assert that raw pointers are non-null on access.
  📝
• Change -O to mean -C opt-level=3 instead of -C opt-level=2 to match Cargo's defaults.
  📝
• Fix emission of overflowing_literals under certain macro environments.
  📝

Platform Support

• Add new Tier 3 targets {aarch64-unknown,x86_64-pc}-nto-qnx710_iosock for supporting Neutrino QNX 7.1 with io-socket network stack.
• Add new Tier 3 targets {aarch64-unknown,x86_64-pc}-nto-qnx800 for supporting Neutrino QNX 8.0 no_std only.
  📝
• Add new Tier 3 targets {x86_64,i686}-win7-windows-gnu.
  These targets are 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.
  📝
• Add new Tier 3 target amdgcn-amd-amdhsa.
  📝
• Add new Tier 3 target x86_64-pc-cygwin.
  📝
• Add new Tier 3 targets {mips,mipsel}-mti-none-elf (initial bare-metal support).
  📝
• Add new Tier 3 target m68k-unknown-none-elf.
  📝
• Add new Tier 3 targets armv7a-nuttx-{eabi,eabihf}, aarch64-unknown-nuttx, and thumbv7a-nuttx-{eabi,eabihf}.
  📝
• Replace i686-unknown-redox target with i586-unknown-redox.
  📝
• Increase baseline CPU of i686-unknown-hurd-gnu to Pentium 4.
  📝

Refer to Rust's platform support page
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, allowing users to examine why the conversion failed.
  📝
• Remove RustcDecodable and RustcEncodable.
  📝
• Deprecate libtest's --logfile option.
  📝
• On recent versions of Windows, std::fs::remove_file will now remove read-only files.
  📝

Stabilized APIs

• {float}::next_down
• {float}::next_up
  📝
• HashMap::get_disjoint_mut
• HashMap::get_disjoint_unchecked_mut
  📝
• NonZero::count_ones
  📝
• Vec::pop_if
  📝
• sync::Once::wait
• sync::Once::wait_force
• sync::OnceLock::wait
  📝
• <[_]>::get_disjoint_mut
• <[_]>::get_disjoint_unchecked_mut
• slice::GetDisjointMutError
  📝

These APIs are now stable in const contexts:

• io::Cursor::get_mut
• io::Cursor::set_position
  📝
• str::is_char_boundary
• str::split_at
• str::split_at_checked
• str::split_at_mut
• str::split_at_mut_checked
  📝
• hint::black_box
  📝

Cargo

• simplify SourceID Ord/Eq
• fix(login): Deprecate CLI token

Rustdoc

• Add sans-serif font setting.
  📝

Compatibility Notes

• The wasm_c_abi future compatibility warning is now a hard error.
  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].
  📝
• The future incompatibility lint cenum_impl_drop_cast has been made into a hard error. 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.
  📝

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.
  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.
  📝

Other

[cuviper]

@rustbot ping relnotes-interest-group

[rustbot]

Hi relnotes-interest-group, this PR adds release notes. Could you review this PR
if you have time? Thanks <3

cc @alex-semenyuk @jieyouxu @joshtriplett @lcnr @traviscross

[joshtriplett]

Made several updates. The new system and process, of editing the underlying relnotes tracking issues and regenerating the release notes from those, seems like a great improvement!

[jieyouxu]

This is much easier to find the actual PR <-> relnotes tracking issue ❤

I made several edits to the underlying relnotes as well.

One nit for the "Stabilized APIs" section is to maybe fully qualify them, i.e. std::sync::Once::wait vs inherent methods on primitive types like {float}::round_down, but maybe that's too noisy.

[cuviper]

One nit for the "Stabilized APIs" section is to maybe fully qualify them, i.e. std::sync::Once::wait

I usually only qualify enough to disambiguate it, but I forgot in this case there's also an iter::Once. Is sync::Once::wait clear enough to you, or do you think it should really have the full path?

(I also tend to leave the crate out when it's available in both core and std, but that doesn't apply in this case.)

[jieyouxu]

I think the short form is good enough (or rather, better since it's less noisy) especially if we already have links to the docs anyway. But in the case of potential ambiguity like iter::Once vs sync::Once, the extra segment(s) like sync::Once might be nice yeah.

Is sync::Once::wait clear enough to you

Yes, that's perfectly clear to me.

[cuviper]

Ok, I updated that, and sync::OnceLock with it just for local consistency, even though that's not ambiguous.

[jieyouxu]

(Changed #138810, #138809 and #138813 to say "Add new Tier 3 target(s) ..." for consistency because apparently I also can't make up my mind if the "target(s)" bit goes before or after the target tuples.)