Use Vec::push_mut when adding a chunk to arenas
This fixes https://github.com/rust-lang/rust/issues/155148, which may or may not be worth fixing on its own merits, but I think `Vec::push_mut` also makes the code nicer.
Fix ICE in `span_extend_prev_while` with multibyte characters
Fixes https://github.com/rust-lang/rust/issues/155037
The function assumed that the character found by `rfind` was always one byte wide, using a hardcoded `1` instead of `c.len_utf8()`. When a multibyte character appeared immediately before the span, this caused the resulting span to point into the middle of a UTF-8 sequence, triggering an assertion failure in `bytepos_to_file_charpos`.
Hexagon: add scalar arch-version target features (v60-v79, audio)
Add target features corresponding to Hexagon LLVM CPU generations to complement the existing HVX vector features. These are needed for gating scalar intrinsics by architecture version.
New features: audio, v60, v62, v65, v66, v67, v68, v69, v71, v73, v75, v79
Each version implies the previous (e.g. v68 implies v67 which implies v66, etc.), matching LLVM's ArchV60-ArchV79 subtarget features.
Also adds hexagon revisions to the feature-hierarchy test to verify the implied feature chains work correctly.
Fix ICE when reporting host-effect errors for const Fn HRTBs in next trait solver
Avoid leaking bound vars into the diagnostic selection path for HRTB host-effect predicates.
Closesrust-lang/rust#151894 .
Update hashbrown to 0.17
The main benefit of this update is to include one potential UB fix and one bug; relevant changelog entries:
* Fixed potential UB in `RawTableInner::fallible_with_capacity` (rust-lang/hashbrown#692)
* Fixed incorrect length if a hasher panics during rehash (rust-lang/hashbrown#710)
cc @Amanieu
Also cc @RalfJung who had also noticed the UB issue with `-Zmiri-recursive-validation`.
unsafe keyword docs: bring back unsafe_op_in_unsafe_fn lint discussion
@traviscross in rust-lang/rust#141471 you asked me to also update the text to account for the edition change. Apparently I did that by entirely removing this part of the discussion (except for a dangling forward reference, a "see below"). Given that old editions still exist and given that `unsafe_op_in_unsafe_fn` is just a lint so the old behavior also still exists on new editions, I am no longer sure that was a good idea, so this brings back the old text with some editing to explain the current situation.
Deprioritize doc(hidden) re-exports in diagnostic paths
Fixesrust-lang/rust#153477.
This is the other half of rust-lang/rust#99698, which fixed the case where the *parent module* is `#[doc(hidden)]` but left the case where the re-export itself is `#[doc(hidden)]` as a FIXME (with a tracking test in `dont-suggest-doc-hidden-variant-for-enum/hidden-child.rs`).
The problem: when a crate does `#[doc(hidden)] pub use core::error::Error`, diagnostics pick up the hidden re-export path instead of the canonical one. For example, `snafu::Error` instead of `std::error::Error`.
Two changes:
In `visible_parent_map`, the `add_child` closure now checks whether the re-export itself is `#[doc(hidden)]` via `reexport_chain` and sends it to `fallback_map`, same treatment as doc-hidden parents and underscore re-exports.
`should_encode_attrs` now returns `true` for `DefKind::Use`. Without this, `#[doc(hidden)]` on `use` items was never written to crate metadata, so `is_doc_hidden` always returned `false` cross-crate. This was the actual root cause, the check in `visible_parent_map` alone isn't enough if the attribute isn't in the metadata.
The existing FIXME test now serves as the regression test. The `.stderr` goes from suggesting `hidden_child::__private::Some(1i32)` to just `Some(1i32)`.
cc @eggyal
Patch musl's CVE-2026-6042 and CVE-2026-40200
- [CVE-2026-6042] is a denial of service in `iconv`.
- [CVE-2026-40200] is an out-of-bounds write in `qsort`.
Neither is relevant to Rust itself, but they could be used in mixed-language projects that link with our `self-contained/libc.a`.
[CVE-2026-6042]: https://www.openwall.com/lists/oss-security/2026/04/09/19
[CVE-2026-40200]: https://www.openwall.com/lists/musl/2026/04/10/3
replace <name> @ ty::AliasTy matches with just using args: <name>_args
ref rust-lang/rust#154941
replace `<name> @ ty::AliasTy` matches with just using `args: <name>_args`
I updated all occurrences where <name> @ ty::AliasTy became unnecessary after the change. In cases where both forms are still used, no changes were made.
r? @WaffleLapkin
fix spurious test failure in `metadata_access_times`
Fixesrust-lang/rust#148408
The metadata_access_times test checks if the creation of a file occurs before another file, this check happens only on Linux. While on Win and Macos we check only that the created metadata is available. Given that the SystemTime is non monotonic as Instant this test could result in failures when the system clock changes.
add `cfg(target_object_format = "...")`
tracking issue: https://github.com/rust-lang/rust/issues/152586
I'm implementing the predicate as `target_object_format`, because that's what is useful to me (for testing `#[link_section = "..."]` where `mach-o` has some extra restrictions) and maps cleanly to the `BinaryFormat` enum that is used internally. There is still room for a future `target_executable_format` when there is a use case.
cc @joshtriplett as the lang sponsor of this feature, @workingjubilee as the author of the proposal.
r? JonathanBrouwer a sidequest from the sidequest that is https://github.com/rust-lang/rust/pull/155065
`ty::Alias`: replace `def_id: did` with `def_id`
related issue: https://github.com/rust-lang/rust/issues/154941
tackling this task:
- [x] replace def_id: did with def_id where possible
r? @WaffleLapkin
Make Box/Rc/Arc::into_array allocator-aware (and add doctest)
Tracking issue for `alloc_slice_into_array`: https://github.com/rust-lang/rust/issues/148082
Tracking issue for `allocator_api`: https://github.com/rust-lang/rust/issues/32838
Make the `into_array` methods on `Box`, `Rc`, and `Arc` allocator-aware.
I think the allocator-aware-ness should not be observable on stable, so these should not be additionally (comment-)gated behind `feature(allocator_api)`, just like e.g. `Box::leak` and `Vec::into_boxed_slice`. The added doctests do not use `feature(allocator_api)`.
@rustbot label T-libs-api
Test(lib/sync): Fix `test_rwlock_max_readers` for x86 Win7
The test recently added in rust-lang/rust#153555 currently systematically deadlocks when running it under i686 Windows 7, but not x86_64 that passes it fine. This therefore fixes the test for the target.
Empirically, the correct value for `MAX_READERS` seems to be `2^28 - 1`: removing the `- 1` re-introduces the deadlock, at least under our testing environment. This fix thus uses this value. However, I have no real justification to support that, because I find myself a bit at a loss when comparing the implementation details, the comment added above the test and what the current value is; some help would therefore be nice in this aspect. Also, the value change is restricted to 32-bit Win7 as there is no evidence to support it should be done for other targets.
cc @roblabla
@rustbot label O-windows-msvc O-windows-7 O-x86_32 A-atomic T-libs
Update libc to v0.2.184
This includes the WASI _SC_* sysconf constants needed for `thread::available_parallelism` on WASI targets (rust-lang/rust#153604).
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#154827 (distinguish "expected a single argument" and "expected an argument" on attribute parsing)
- rust-lang/rust#155104 (bootstrap: auto-patch libgccjit.so for NixOS)
- rust-lang/rust#155120 (Use a linting node closer the parsing of `#[cfg_attr]`)
Use a linting node closer the parsing of `#[cfg_attr]`
The parsing of `#[cfg_attr]` unconditionally used the crate-root as a linting node to attach lints, but the `unexpected_cfgs` lint can fire when parsing the attribute and users expect to be able to allow it at places other than the crate-root.
Let's instead use the linting node id, which is unfortunately always the parent but that's better than the crate-root when you are in a sub-module.
The parsing of `#[cfg]` and other already use the expansion linting node id, so no change required there.
Related to https://github.com/rust-lang/rust/issues/155118
bootstrap: auto-patch libgccjit.so for NixOS
Currently all downloaded rustc and LLVM components are auto patched on NixOS, but this is not done for libgccjit.so, so when GCC backend is enabled on NixOS, the build ICEs with errors like this:
thread 'rustc' (2286205) panicked at compiler/rustc_codegen_gcc/src/lib.rs:191:9:
Cannot load libgccjit.so: libzstd.so.1: cannot open shared object file: No such file or directory
Fix this by auto-patch libgccjit.so, too. `zstd` is added to the dependency environment.
mejrs