https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=auto 2025-10-04T10:31:27+00:00 2025-10-04T10:31:27+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-10-04T10:31:27+00:00 urn:sha1:82ccda32f48d52d1cadd0eb7826e72bf5f83bf9b interpret `#[used]` as `#[used(compiler)]` on illumos helps rust-lang/rust#146169 not be as painful: fixes the illumos regression in rust-lang/rust#140872, but `#[used(linker)]` is still erroneous on illumos generally. illumos' `ld` does not support a flag like either SHF_GNU_RETAIN or SHF_SUNW_NODISCARD, so there is no way to communicate `#[used(linker)]` for that target. Setting `USED_LINKER` to try results in LLVM setting SHF_SUNW_NODISCARD for Solaris-like targets, which is an unknown section header flag for illumos `ld` and prevents sections from being merged that otherwise would. As a motivating example, the `inventory` crate produces `#[used]` items to merge into `.init_array`. Because those items have an unknown section header flag they are not merged with the default `.init_array` with `frame_dummy`, and end up never executed. Downgrading `#[used]` to `#[used(compiler)]` on illumos keeps so-attributed items as preserved as they had been before https://github.com/rust-lang/rust/pull/140872. As was the case before that change, because rustc passes `-z ignore` to illumos `ld`, it's possible that `used` sections are GC'd at link time. https://github.com/rust-lang/rust/issues/146169 describes this unfortunate circumstance. ---- as it turns out, `tests/ui/attributes/used_with_archive.rs` had broken on `x86_64-unknown-illumos`, and this patch fixes it. the trials and tribulations of tier 2 :( r? ``@Noratrieb`` probably? 2025-10-03T22:03:24+00:00 iximeow iximeow@oxide.computer 2025-09-28T03:21:45+00:00 urn:sha1:c721fa243825255c0f195d4282021e7c263c3e7f illumos' `ld` does not support a flag like either SHF_GNU_RETAIN or SHF_SUNW_NODISCARD, so there is no way to communicate `#[used(linker)]` for that target. Setting `USED_LINKER` to try results in LLVM setting SHF_SUNW_NODISCARD for Solaris-like targets, which is an unknown section header flag for illumos `ld` and prevents sections from being merged that otherwise would. As a motivating example, the `inventory` crate produces `#[used]` items to merge into `.init_array`. Because those items have an unknown section header flag they are not merged with the default `.init_array` with `frame_dummy`, and end up never executed. Downgrading `#[used]` to `#[used(compiler)]` on illumos keeps so-attributed items as preserved as they had been before https://github.com/rust-lang/rust/pull/140872. As was the case before that change, because rustc passes `-z ignore` to illumos `ld`, it's possible that `used` sections are GC'd at link time. https://github.com/rust-lang/rust/issues/146169 describes this unfortunate circumstance. 2025-10-02T21:43:10+00:00 bors bors@rust-lang.org 2025-10-02T21:43:10+00:00 urn:sha1:8d603ef2879fd263f8e9aea340b4c035ed7973db Extending `#[rustc_force_inline]` to be applicable to inherent methods `#[rustc_force_inline]` is an internal-only attribute similar to `#[inline(always)]` but which emits an error if inlining cannot occur. rustc_force_inline uses the MIR inliner to do this and has limitations on where it can be applied to ensure that an error is always emitted if inlining can't happen (e.g. it can't be applied to trait methods because calls to those can't always be resolved). `#[rustc_force_inline]` is motivated by AArch64 pointer authentication intrinsics where it is vital for the security properties of these intrinsics that they do not exist in standalone functions that could be used as gadgets in an exploit (if they could, then you could sign whatever pointers you want, for example, which is bad, but if you force inlining, then you can't jump to a reusable function containing only these instructions). Since its initial implementation, `#[rustc_force_inline]` could only be applied to free functions. This can be relaxed to also allow inherent methods while still preserving the desired properties. In a work-in-progress patch for manual pointer authentication intrinsics, it is useful to introduce types with inherent methods that would need to be force inlined. r? `@saethlin` 2025-10-02T10:30:11+00:00 Reuben Cruise reuben.cruise@arm.com 2025-09-25T15:11:34+00:00 urn:sha1:5bf5e7116099d85a99d047cfa43db155074e594a - Changes parser to allow application to inherent methods. - Adds tests to confirm extended functionality works just as the existing. 2025-10-02T08:27:49+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-10-02T08:27:49+00:00 urn:sha1:ac7beab527861103dd1e1515d534f87956786554 mbe: Implement `unsafe` attribute rules This implements `unsafe attr` rules for declarative `macro_rules!` attributes, as specified in [RFC 3697](https://github.com/rust-lang/rfcs/pull/3697). An invocation of an attribute that uses an `unsafe attr` rule requires the `unsafe(attr(...))` syntax. An invocation of an attribute that uses an ordinary `attr` rule must *not* use the `unsafe(attr(...))` syntax. `unsafe` is only supported on an `attr` rule, not any other kind of `macro_rules!` rule. Tracking issue for `macro_rules!` attributes: https://github.com/rust-lang/rust/issues/143547 2025-10-01T23:19:39+00:00 Josh Triplett josh@joshtriplett.org 2025-09-14T08:17:51+00:00 urn:sha1:6bff1abf9d3c171d2380aacb8b4c6f52580192b3 2025-09-29T11:06:45+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-29T11:06:45+00:00 urn:sha1:08616a17457bb93eb177d9189f92345d1924294d Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library Now that rust-lang/rust#137122 has landed, we can replace stuff that looks like: ```rust let a: &[T]; let b: &[T]; let eq = a.len() == b.len() && a.iter().zip(b).all(|(a,b)| a == b) ``` with the much simpler `a.iter().eq(b)`, without losing the perf benefit of the different-length-fast-path. Also dogfooded `Iterator::eq_by` (cc rust-lang/rust#64295 ) while I'm at it. First commit (4d1b6fad230f8a5ccceccc7562eadc4ea50059da) should be very straightforward to review, second one (049a4606cb3906787aedf508ee8eea09c2bb3b9a) is slightly more creative, but IMHO a nice cleanup. 2025-09-29T05:08:05+00:00 Yotam Ofek yotam.ofek@gmail.com 2025-09-27T17:57:50+00:00 urn:sha1:68a7c250788833305f73f816b284aafa9e62370a 2025-09-27T17:32:14+00:00 Jana Dönszelmann jana@donsz.nl 2025-09-16T18:52:17+00:00 urn:sha1:b3631e1174e222bf1dadf1549cfd0f717ebf6d64 2025-09-26T16:11:09+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-26T16:11:09+00:00 urn:sha1:d09bb02eb50c5b7137eb9a14f546540fa24083cf port `#[debugger_visualizer]` to the new attribute system