Skip to content

Conversation

LuigiPiucco
Copy link
Contributor

@LuigiPiucco LuigiPiucco commented May 19, 2025

This PR relaxes the ub_check in the read_volatile/write_volatile pointer operations to allow passing null. This is needed to support processors which hard-code peripheral registers on address 0, like the AVR chip ATtiny1626. LLVM understands this as valid and handles it correctly, as tested in my PR to add a note about it (rustc generates the same LLVM IR as expected there when this PR is applied, and consequently the same AVR assembly).

Follow-up and implementation of the discussions in:

r? @RalfJung

Also fixes rust-lang/unsafe-code-guidelines#29 (about as good as it'll get, null will likely never be a "normal" address in Rust)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 19, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member

RalfJung commented May 20, 2025

Cc @rust-lang/opsem @nikic

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a question, and I also pushed a commit where I did an edit pass over the read_volatile docs. If you agree with what I did there, could you apply the same edits to write_volatile?

@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member

@rustbot author

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 23, 2025
@rustbot
Copy link
Collaborator

rustbot commented May 23, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label May 23, 2025
@LuigiPiucco LuigiPiucco force-pushed the volatile-null branch 2 times, most recently from ccb7d35 to aae2722 Compare May 23, 2025 16:22
@RalfJung
Copy link
Member

RalfJung commented May 23, 2025

It'd help if you didn't amend and force-push my commit, then I could much easier see what you changed on top of my changes...

Now I guess I'll have to download your PR and compare locally against my commit (which was 3ea26bd).

In general, please do not force-push while review is still in progress. Github is terrible at dealing with force-pushes. The reviewer will ask you to squash the commits before approval.

@LuigiPiucco
Copy link
Contributor Author

Sorry, I'll add new commits instead of amending from now on.

Other projects I worked on seemed to prefer amending, that's why I was doing it like that.

@RalfJung
Copy link
Member

RalfJung commented May 23, 2025

Yeah, every project finds their own way to work around github's deficiencies. :/ I've not yet seen a good way to deal with github's abysmal treatment of force-pushes, though. I often have to pretty much re-review a PR as github provides 0 support for figuring out what actually changes in a series of pushes and force-pushes.

When you create your first PR here, a bot posts a message telling you about our PR workflow. But it's probably easy to forget that...

@LuigiPiucco
Copy link
Contributor Author

@rustbot ready

If the PR needs further revision, would you prefer to run the author/ready sequence every time, or to avoid it if we're both replying quickly? I don't mind the pings, but if you do I can adjust.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 23, 2025
@RalfJung
Copy link
Member

An explicit "ready for review" signal is always a good idea. :)

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point about the inter-thread synchronization, let's repeat that in the function-level docs. As usual, my read comments apply to write as well.

@RalfJung RalfJung added T-lang Relevant to the language team T-opsem Relevant to the opsem team labels May 23, 2025
@LuigiPiucco
Copy link
Contributor Author

Both changes applied, it should be good now.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 18, 2025
@RalfJung
Copy link
Member

Looks good, thanks!
@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Jul 19, 2025

📌 Commit 8a8717e has been approved by RalfJung

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 19, 2025
@RalfJung RalfJung added the relnotes Marks issues that should be documented in the release notes of the next release. label Jul 19, 2025
Kobzol added a commit to Kobzol/rust that referenced this pull request Jul 19, 2025
Allow volatile access to non-Rust memory, including address 0 This PR relaxes the `ub_check` in the `read_volatile`/`write_volatile` pointer operations to allow passing null. This is needed to support processors which hard-code peripheral registers on address 0, like the AVR chip ATtiny1626. LLVM understands this as valid and handles it correctly, as tested in my [PR to add a note about it](llvm/llvm-project@6387c82#diff-81bbb96298c32fa901beb82ab3b97add27a410c01d577c1f8c01000ed2055826) (rustc generates the same LLVM IR as expected there when this PR is applied, and consequently the same AVR assembly). Follow-up and implementation of the discussions in: - https://internals.rust-lang.org/t/pre-rfc-conditionally-supported-volatile-access-to-address-0/12881/7 - Rahix/avr-device#185; - [#t-lang > Adding the possibility of volatile access to address 0](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Adding.20the.20possibility.20of.20volatile.20access.20to.20address.200/with/513303502) - https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303 r? `@RalfJung` Also fixes rust-lang/unsafe-code-guidelines#29 (about as good as it'll get, null will likely never be a "normal" address in Rust)
jhpratt added a commit to jhpratt/rust that referenced this pull request Jul 20, 2025
Allow volatile access to non-Rust memory, including address 0 This PR relaxes the `ub_check` in the `read_volatile`/`write_volatile` pointer operations to allow passing null. This is needed to support processors which hard-code peripheral registers on address 0, like the AVR chip ATtiny1626. LLVM understands this as valid and handles it correctly, as tested in my [PR to add a note about it](llvm/llvm-project@6387c82#diff-81bbb96298c32fa901beb82ab3b97add27a410c01d577c1f8c01000ed2055826) (rustc generates the same LLVM IR as expected there when this PR is applied, and consequently the same AVR assembly). Follow-up and implementation of the discussions in: - https://internals.rust-lang.org/t/pre-rfc-conditionally-supported-volatile-access-to-address-0/12881/7 - Rahix/avr-device#185; - [#t-lang > Adding the possibility of volatile access to address 0](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Adding.20the.20possibility.20of.20volatile.20access.20to.20address.200/with/513303502) - https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303 r? ``@RalfJung`` Also fixes rust-lang/unsafe-code-guidelines#29 (about as good as it'll get, null will likely never be a "normal" address in Rust)
fee1-dead added a commit to fee1-dead-contrib/rust that referenced this pull request Jul 20, 2025
Allow volatile access to non-Rust memory, including address 0 This PR relaxes the `ub_check` in the `read_volatile`/`write_volatile` pointer operations to allow passing null. This is needed to support processors which hard-code peripheral registers on address 0, like the AVR chip ATtiny1626. LLVM understands this as valid and handles it correctly, as tested in my [PR to add a note about it](llvm/llvm-project@6387c82#diff-81bbb96298c32fa901beb82ab3b97add27a410c01d577c1f8c01000ed2055826) (rustc generates the same LLVM IR as expected there when this PR is applied, and consequently the same AVR assembly). Follow-up and implementation of the discussions in: - https://internals.rust-lang.org/t/pre-rfc-conditionally-supported-volatile-access-to-address-0/12881/7 - Rahix/avr-device#185; - [#t-lang > Adding the possibility of volatile access to address 0](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Adding.20the.20possibility.20of.20volatile.20access.20to.20address.200/with/513303502) - https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303 r? ```@RalfJung``` Also fixes rust-lang/unsafe-code-guidelines#29 (about as good as it'll get, null will likely never be a "normal" address in Rust)
bors added a commit that referenced this pull request Jul 20, 2025
Rollup of 12 pull requests Successful merges: - #141260 (Allow volatile access to non-Rust memory, including address 0) - #143604 (Stabilize `const_float_round_methods`) - #143833 (Ban projecting into SIMD types [MCP838]) - #143988 ([rustdoc] Make aliases search support partial matching) - #144078 (Fix debuginfo-lto-alloc.rs test) - #144111 (Remove deprecated `MaybeUninit` slice methods) - #144116 (Fixes for LLVM 21) - #144134 (Cleanup unicode table gen) - #144142 (Add implicit sized bound to trait ascription types) - #144148 (Remove pretty print hack for async blocks) - #144169 (interpret: fix TypeId pointers being considered data pointers) - #144196 (Initialize mingw for the runner's user) r? `@ghost` `@rustbot` modify labels: rollup
bors added a commit that referenced this pull request Jul 20, 2025
Rollup of 11 pull requests Successful merges: - #141260 (Allow volatile access to non-Rust memory, including address 0) - #143604 (Stabilize `const_float_round_methods`) - #143988 ([rustdoc] Make aliases search support partial matching) - #144078 (Fix debuginfo-lto-alloc.rs test) - #144111 (Remove deprecated `MaybeUninit` slice methods) - #144116 (Fixes for LLVM 21) - #144134 (Cleanup unicode table gen) - #144142 (Add implicit sized bound to trait ascription types) - #144148 (Remove pretty print hack for async blocks) - #144169 (interpret: fix TypeId pointers being considered data pointers) - #144196 (Initialize mingw for the runner's user) r? `@ghost` `@rustbot` modify labels: rollup
@bors bors merged commit 6d7d366 into rust-lang:master Jul 20, 2025
11 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 20, 2025
rust-timer added a commit that referenced this pull request Jul 20, 2025
Rollup merge of #141260 - LuigiPiucco:volatile-null, r=RalfJung Allow volatile access to non-Rust memory, including address 0 This PR relaxes the `ub_check` in the `read_volatile`/`write_volatile` pointer operations to allow passing null. This is needed to support processors which hard-code peripheral registers on address 0, like the AVR chip ATtiny1626. LLVM understands this as valid and handles it correctly, as tested in my [PR to add a note about it](llvm/llvm-project@6387c82#diff-81bbb96298c32fa901beb82ab3b97add27a410c01d577c1f8c01000ed2055826) (rustc generates the same LLVM IR as expected there when this PR is applied, and consequently the same AVR assembly). Follow-up and implementation of the discussions in: - https://internals.rust-lang.org/t/pre-rfc-conditionally-supported-volatile-access-to-address-0/12881/7 - Rahix/avr-device#185; - [#t-lang > Adding the possibility of volatile access to address 0](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Adding.20the.20possibility.20of.20volatile.20access.20to.20address.200/with/513303502) - https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303 r? ````@RalfJung```` Also fixes rust-lang/unsafe-code-guidelines#29 (about as good as it'll get, null will likely never be a "normal" address in Rust)
@LuigiPiucco LuigiPiucco deleted the volatile-null branch July 20, 2025 14:28
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Jul 21, 2025
Rollup of 11 pull requests Successful merges: - rust-lang/rust#141260 (Allow volatile access to non-Rust memory, including address 0) - rust-lang/rust#143604 (Stabilize `const_float_round_methods`) - rust-lang/rust#143988 ([rustdoc] Make aliases search support partial matching) - rust-lang/rust#144078 (Fix debuginfo-lto-alloc.rs test) - rust-lang/rust#144111 (Remove deprecated `MaybeUninit` slice methods) - rust-lang/rust#144116 (Fixes for LLVM 21) - rust-lang/rust#144134 (Cleanup unicode table gen) - rust-lang/rust#144142 (Add implicit sized bound to trait ascription types) - rust-lang/rust#144148 (Remove pretty print hack for async blocks) - rust-lang/rust#144169 (interpret: fix TypeId pointers being considered data pointers) - rust-lang/rust#144196 (Initialize mingw for the runner's user) r? `@ghost` `@rustbot` modify labels: rollup
Muscraft pushed a commit to Muscraft/rust that referenced this pull request Jul 21, 2025
Allow volatile access to non-Rust memory, including address 0 This PR relaxes the `ub_check` in the `read_volatile`/`write_volatile` pointer operations to allow passing null. This is needed to support processors which hard-code peripheral registers on address 0, like the AVR chip ATtiny1626. LLVM understands this as valid and handles it correctly, as tested in my [PR to add a note about it](llvm/llvm-project@6387c82#diff-81bbb96298c32fa901beb82ab3b97add27a410c01d577c1f8c01000ed2055826) (rustc generates the same LLVM IR as expected there when this PR is applied, and consequently the same AVR assembly). Follow-up and implementation of the discussions in: - https://internals.rust-lang.org/t/pre-rfc-conditionally-supported-volatile-access-to-address-0/12881/7 - Rahix/avr-device#185; - [#t-lang > Adding the possibility of volatile access to address 0](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Adding.20the.20possibility.20of.20volatile.20access.20to.20address.200/with/513303502) - https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303 r? ````@RalfJung```` Also fixes rust-lang/unsafe-code-guidelines#29 (about as good as it'll get, null will likely never be a "normal" address in Rust)
Muscraft pushed a commit to Muscraft/rust that referenced this pull request Jul 21, 2025
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#141260 (Allow volatile access to non-Rust memory, including address 0) - rust-lang#143604 (Stabilize `const_float_round_methods`) - rust-lang#143988 ([rustdoc] Make aliases search support partial matching) - rust-lang#144078 (Fix debuginfo-lto-alloc.rs test) - rust-lang#144111 (Remove deprecated `MaybeUninit` slice methods) - rust-lang#144116 (Fixes for LLVM 21) - rust-lang#144134 (Cleanup unicode table gen) - rust-lang#144142 (Add implicit sized bound to trait ascription types) - rust-lang#144148 (Remove pretty print hack for async blocks) - rust-lang#144169 (interpret: fix TypeId pointers being considered data pointers) - rust-lang#144196 (Initialize mingw for the runner's user) r? `@ghost` `@rustbot` modify labels: rollup
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Jul 29, 2025
Allow volatile access to non-Rust memory, including address 0 This PR relaxes the `ub_check` in the `read_volatile`/`write_volatile` pointer operations to allow passing null. This is needed to support processors which hard-code peripheral registers on address 0, like the AVR chip ATtiny1626. LLVM understands this as valid and handles it correctly, as tested in my [PR to add a note about it](llvm/llvm-project@6387c82#diff-81bbb96298c32fa901beb82ab3b97add27a410c01d577c1f8c01000ed2055826) (rustc generates the same LLVM IR as expected there when this PR is applied, and consequently the same AVR assembly). Follow-up and implementation of the discussions in: - https://internals.rust-lang.org/t/pre-rfc-conditionally-supported-volatile-access-to-address-0/12881/7 - Rahix/avr-device#185; - [#t-lang > Adding the possibility of volatile access to address 0](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Adding.20the.20possibility.20of.20volatile.20access.20to.20address.200/with/513303502) - https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303 r? ````@RalfJung```` Also fixes rust-lang/unsafe-code-guidelines#29 (about as good as it'll get, null will likely never be a "normal" address in Rust)
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request Sep 20, 2025
Pkgsrc changes: * Adjust patches to adapt to upstream changes and new versions. * assosicated checksums Upstream changes relative to 1.89.0: Version 1.90 (2025-09-18) ========================== Language -------- - [Split up the `unknown_or_malformed_diagnostic_attributes` lint] (rust-lang/rust#140717). This lint has been split up into four finer-grained lints, with `unknown_or_malformed_diagnostic_attributes` now being the lint group that contains these lints: 1. `unknown_diagnostic_attributes`: unknown to the current compiler 2. `misplaced_diagnostic_attributes`: placed on the wrong item 3. `malformed_diagnostic_attributes`: malformed attribute syntax or options 4. `malformed_diagnostic_format_literals`: malformed format string literal - [Allow constants whose final value has references to mutable/external memory, but reject such constants as patterns] (rust-lang/rust#140942) - [Allow volatile access to non-Rust memory, including address 0] (rust-lang/rust#141260) Compiler -------- - [Use `lld` by default on `x86_64-unknown-linux-gnu`] (rust-lang/rust#140525). - [Tier 3 `musl` targets now link dynamically by default] (rust-lang/rust#144410). Affected targets: - `mips64-unknown-linux-muslabi64` - `powerpc64-unknown-linux-musl` - `powerpc-unknown-linux-musl` - `powerpc-unknown-linux-muslspe` - `riscv32gc-unknown-linux-musl` - `s390x-unknown-linux-musl` - `thumbv7neon-unknown-linux-musleabihf` Platform Support ---------------- - [Demote `x86_64-apple-darwin` to Tier 2 with host tools] (rust-lang/rust#145252) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html Libraries --------- - [Stabilize `u*::{checked,overflowing,saturating,wrapping}_sub_signed`] (rust-lang/rust#126043) - [Allow comparisons between `CStr`, `CString`, and `Cow<CStr>`] (rust-lang/rust#137268) - [Remove some unsized tuple impls since unsized tuples can't be constructed] (rust-lang/rust#138340) - [Set `MSG_NOSIGNAL` for `UnixStream`] (rust-lang/rust#140005) - [`proc_macro::Ident::new` now supports `$crate`.] (rust-lang/rust#141996) - [Guarantee the pointer returned from `Thread::into_raw` has at least 8 bytes of alignment] (rust-lang/rust#143859) Stabilized APIs --------------- - [`u{n}::checked_sub_signed`] (https://doc.rust-lang.org/stable/std/primitive.usize.html#method.checked_sub_signed) - [`u{n}::overflowing_sub_signed`] (https://doc.rust-lang.org/stable/std/primitive.usize.html#method.overflowing_sub_signed) - [`u{n}::saturating_sub_signed`] (https://doc.rust-lang.org/stable/std/primitive.usize.html#method.saturating_sub_signed) - [`u{n}::wrapping_sub_signed`] (https://doc.rust-lang.org/stable/std/primitive.usize.html#method.wrapping_sub_signed) - [`impl Copy for IntErrorKind`] (https://doc.rust-lang.org/stable/std/num/enum.IntErrorKind.html#impl-Copy-for-IntErrorKind) - [`impl Hash for IntErrorKind`] (https://doc.rust-lang.org/stable/std/num/enum.IntErrorKind.html#impl-Hash-for-IntErrorKind) - [`impl PartialEq<&CStr> for CStr`] (https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#impl-PartialEq%3C%26CStr%3E-for-CStr) - [`impl PartialEq<CString> for CStr`] (https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#impl-PartialEq%3CCString%3E-for-CStr) - [`impl PartialEq<Cow<CStr>> for CStr`] (https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#impl-PartialEq%3CCow%3C'_,+CStr%3E%3E-for-CStr) - [`impl PartialEq<&CStr> for CString`] (https://doc.rust-lang.org/stable/std/ffi/struct.CString.html#impl-PartialEq%3C%26CStr%3E-for-CString) - [`impl PartialEq<CStr> for CString`] (https://doc.rust-lang.org/stable/std/ffi/struct.CString.html#impl-PartialEq%3CCStr%3E-for-CString) - [`impl PartialEq<Cow<CStr>> for CString`] (https://doc.rust-lang.org/stable/std/ffi/struct.CString.html#impl-PartialEq%3CCow%3C'_,+CStr%3E%3E-for-CString) - [`impl PartialEq<&CStr> for Cow<CStr>`] (https://doc.rust-lang.org/stable/std/borrow/enum.Cow.html#impl-PartialEq%3C%26CStr%3E-for-Cow%3C'_,+CStr%3E) - [`impl PartialEq<CStr> for Cow<CStr>`] (https://doc.rust-lang.org/stable/std/borrow/enum.Cow.html#impl-PartialEq%3CCStr%3E-for-Cow%3C'_,+CStr%3E) - [`impl PartialEq<CString> for Cow<CStr>`] (https://doc.rust-lang.org/stable/std/borrow/enum.Cow.html#impl-PartialEq%3CCString%3E-for-Cow%3C'_,+CStr%3E) These previously stable APIs are now stable in const contexts: - [`<[T]>::reverse`] (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.reverse) - [`f32::floor`] (https://doc.rust-lang.org/stable/std/primitive.f32.html#method.floor) - [`f32::ceil`] (https://doc.rust-lang.org/stable/std/primitive.f32.html#method.ceil) - [`f32::trunc`] (https://doc.rust-lang.org/stable/std/primitive.f32.html#method.trunc) - [`f32::fract`] (https://doc.rust-lang.org/stable/std/primitive.f32.html#method.fract) - [`f32::round`] (https://doc.rust-lang.org/stable/std/primitive.f32.html#method.round) - [`f32::round_ties_even`] (https://doc.rust-lang.org/stable/std/primitive.f32.html#method.round_ties_even) - [`f64::floor`] (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.floor) - [`f64::ceil`] (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.ceil) - [`f64::trunc`] (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.trunc) - [`f64::fract`] (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.fract) - [`f64::round`] (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.round) - [`f64::round_ties_even`] (https://doc.rust-lang.org/stable/std/primitive.f64.html#method.round_ties_even) Cargo ----- - [Add `http.proxy-cainfo` config for proxy certs] (rust-lang/cargo#15374) - [Use `gix` for `cargo package`] (rust-lang/cargo#15534) - [feat(publish): Stabilize multi-package publishing] (rust-lang/cargo#15636) Rustdoc ----- - [Add ways to collapse all impl blocks] (rust-lang/rust#141663). Previously the "Summary" button and "-" keyboard shortcut would never collapse `impl` blocks, now they do when shift is held - [Display unsafe attributes with `unsafe()` wrappers] (rust-lang/rust#143662) Compatibility Notes ------------------- - [Use `lld` by default on `x86_64-unknown-linux-gnu`] (rust-lang/rust#140525). See also <https://blog.rust-lang.org/2025/09/01/rust-lld-on-1.90.0-stable/>. - [Make `core::iter::Fuse`'s `Default` impl construct `I::default()` internally as promised in the docs instead of always being empty] (rust-lang/rust#140985) - [Set `MSG_NOSIGNAL` for `UnixStream`] (rust-lang/rust#140005) This may change program behavior but results in the same behavior as other primitives (e.g., stdout, network sockets). Programs relying on signals to terminate them should update handling of sockets to handle errors on write by exiting. - [On Unix `std::env::home_dir` will use the fallback if the `HOME` environment variable is empty] (rust-lang/rust#141840) - We now [reject unsupported `extern "{abi}"`s consistently in all positions] (rust-lang/rust#142134). This primarily affects the use of implementing traits on an `extern "{abi}"` function pointer, like `extern "stdcall" fn()`, on a platform that doesn't support that, like aarch64-unknown-linux-gnu. Direct usage of these unsupported ABI strings by declaring or defining functions was already rejected, so this is only a change for consistency. - [const-eval: error when initializing a static writes to that static] (rust-lang/rust#143084) - [Check that the `proc_macro_derive` macro has correct arguments when applied to the crate root] (rust-lang/rust#143607)
tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request Sep 24, 2025
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [rust](https://github.com/rust-lang/rust) | minor | `1.89.0` -> `1.90.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.90.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1900-2025-09-18) [Compare Source](rust-lang/rust@1.89.0...1.90.0) \=========================== <a id="1.90-Language"></a> ## Language - [Split up the `unknown_or_malformed_diagnostic_attributes` lint](rust-lang/rust#140717). This lint has been split up into four finer-grained lints, with `unknown_or_malformed_diagnostic_attributes` now being the lint group that contains these lints: 1. `unknown_diagnostic_attributes`: unknown to the current compiler 2. `misplaced_diagnostic_attributes`: placed on the wrong item 3. `malformed_diagnostic_attributes`: malformed attribute syntax or options 4. `malformed_diagnostic_format_literals`: malformed format string literal - [Allow constants whose final value has references to mutable/external memory, but reject such constants as patterns](rust-lang/rust#140942) - [Allow volatile access to non-Rust memory, including address 0](rust-lang/rust#141260) <a id="1.90-Compiler"></a> ## Compiler - [Use `lld` by default on `x86_64-unknown-linux-gnu`](rust-lang/rust#140525). - [Tier 3 `musl` targets now link dynamically by default](rust-lang/rust#144410). Affected targets: - `mips64-unknown-linux-muslabi64` - `powerpc64-unknown-linux-musl` - `powerpc-unknown-linux-musl` - `powerpc-unknown-linux-muslspe` - `riscv32gc-unknown-linux-musl` - `s390x-unknown-linux-musl` - `thumbv7neon-unknown-linux-musleabihf` <a id="1.90-Platform-Support"></a> ## Platform Support - [Demote `x86_64-apple-darwin` to Tier 2 with host tools](rust-lang/rust#145252) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html <a id="1.90-Libraries"></a> ## Libraries - [Stabilize `u*::{checked,overflowing,saturating,wrapping}_sub_signed`](rust-lang/rust#126043) - [Allow comparisons between `CStr`, `CString`, and `Cow<CStr>`](rust-lang/rust#137268) - [Remove some unsized tuple impls since unsized tuples can't be constructed](rust-lang/rust#138340) - [Set `MSG_NOSIGNAL` for `UnixStream`](rust-lang/rust#140005) - [`proc_macro::Ident::new` now supports `$crate`.](rust-lang/rust#141996) - [Guarantee the pointer returned from `Thread::into_raw` has at least 8 bytes of alignment](rust-lang/rust#143859) <a id="1.90-Stabilized-APIs"></a> ## Stabilized APIs - [`u{n}::checked_sub_signed`](https://doc.rust-lang.org/stable/std/primitive.usize.html#method.checked_sub_signed) - [`u{n}::overflowing_sub_signed`](https://doc.rust-lang.org/stable/std/primitive.usize.html#method.overflowing_sub_signed) - [`u{n}::saturating_sub_signed`](https://doc.rust-lang.org/stable/std/primitive.usize.html#method.saturating_sub_signed) - [`u{n}::wrapping_sub_signed`](https://doc.rust-lang.org/stable/std/primitive.usize.html#method.wrapping_sub_signed) - [`impl Copy for IntErrorKind`](https://doc.rust-lang.org/stable/std/num/enum.IntErrorKind.html#impl-Copy-for-IntErrorKind) - [`impl Hash for IntErrorKind`](https://doc.rust-lang.org/stable/std/num/enum.IntErrorKind.html#impl-Hash-for-IntErrorKind) - [`impl PartialEq<&CStr> for CStr`](https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#impl-PartialEq%3C%26CStr%3E-for-CStr) - [`impl PartialEq<CString> for CStr`](https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#impl-PartialEq%3CCString%3E-for-CStr) - [`impl PartialEq<Cow<CStr>> for CStr`](https://doc.rust-lang.org/stable/std/ffi/struct.CStr.html#impl-PartialEq%3CCow%3C'_,+CStr%3E%3E-for-CStr) - [`impl PartialEq<&CStr> for CString`](https://doc.rust-lang.org/stable/std/ffi/struct.CString.html#impl-PartialEq%3C%26CStr%3E-for-CString) - [`impl PartialEq<CStr> for CString`](https://doc.rust-lang.org/stable/std/ffi/struct.CString.html#impl-PartialEq%3CCStr%3E-for-CString) - [`impl PartialEq<Cow<CStr>> for CString`](https://doc.rust-lang.org/stable/std/ffi/struct.CString.html#impl-PartialEq%3CCow%3C'_,+CStr%3E%3E-for-CString) - [`impl PartialEq<&CStr> for Cow<CStr>`](https://doc.rust-lang.org/stable/std/borrow/enum.Cow.html#impl-PartialEq%3C%26CStr%3E-for-Cow%3C'_,+CStr%3E) - [`impl PartialEq<CStr> for Cow<CStr>`](https://doc.rust-lang.org/stable/std/borrow/enum.Cow.html#impl-PartialEq%3CCStr%3E-for-Cow%3C'_,+CStr%3E) - [`impl PartialEq<CString> for Cow<CStr>`](https://doc.rust-lang.org/stable/std/borrow/enum.Cow.html#impl-PartialEq%3CCString%3E-for-Cow%3C'_,+CStr%3E) These previously stable APIs are now stable in const contexts: - [`<[T]>::reverse`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.reverse) - [`f32::floor`](https://doc.rust-lang.org/stable/std/primitive.f32.html#method.floor) - [`f32::ceil`](https://doc.rust-lang.org/stable/std/primitive.f32.html#method.ceil) - [`f32::trunc`](https://doc.rust-lang.org/stable/std/primitive.f32.html#method.trunc) - [`f32::fract`](https://doc.rust-lang.org/stable/std/primitive.f32.html#method.fract) - [`f32::round`](https://doc.rust-lang.org/stable/std/primitive.f32.html#method.round) - [`f32::round_ties_even`](https://doc.rust-lang.org/stable/std/primitive.f32.html#method.round_ties_even) - [`f64::floor`](https://doc.rust-lang.org/stable/std/primitive.f64.html#method.floor) - [`f64::ceil`](https://doc.rust-lang.org/stable/std/primitive.f64.html#method.ceil) - [`f64::trunc`](https://doc.rust-lang.org/stable/std/primitive.f64.html#method.trunc) - [`f64::fract`](https://doc.rust-lang.org/stable/std/primitive.f64.html#method.fract) - [`f64::round`](https://doc.rust-lang.org/stable/std/primitive.f64.html#method.round) - [`f64::round_ties_even`](https://doc.rust-lang.org/stable/std/primitive.f64.html#method.round_ties_even) <a id="1.90-Cargo"></a> ## Cargo - [Add `http.proxy-cainfo` config for proxy certs](rust-lang/cargo#15374) - [Use `gix` for `cargo package`](rust-lang/cargo#15534) - [feat(publish): Stabilize multi-package publishing](rust-lang/cargo#15636) <a id="1.90-Rustdoc"></a> ## Rustdoc - [Add ways to collapse all impl blocks](rust-lang/rust#141663). Previously the "Summary" button and "-" keyboard shortcut would never collapse `impl` blocks, now they do when shift is held - [Display unsafe attributes with `unsafe()` wrappers](rust-lang/rust#143662) <a id="1.90-Compatibility-Notes"></a> ## Compatibility Notes - [Use `lld` by default on `x86_64-unknown-linux-gnu`](rust-lang/rust#140525). See also <https://blog.rust-lang.org/2025/09/01/rust-lld-on-1.90.0-stable/>. - [Make `core::iter::Fuse`'s `Default` impl construct `I::default()` internally as promised in the docs instead of always being empty](rust-lang/rust#140985) - [Set `MSG_NOSIGNAL` for `UnixStream`](rust-lang/rust#140005) This may change program behavior but results in the same behavior as other primitives (e.g., stdout, network sockets). Programs relying on signals to terminate them should update handling of sockets to handle errors on write by exiting. - [On Unix `std::env::home_dir` will use the fallback if the `HOME` environment variable is empty](rust-lang/rust#141840) - We now [reject unsupported `extern "{abi}"`s consistently in all positions](rust-lang/rust#142134). This primarily affects the use of implementing traits on an `extern "{abi}"` function pointer, like `extern "stdcall" fn()`, on a platform that doesn't support that, like aarch64-unknown-linux-gnu. Direct usage of these unsupported ABI strings by declaring or defining functions was already rejected, so this is only a change for consistency. - [const-eval: error when initializing a static writes to that static](rust-lang/rust#143084) - [Check that the `proc_macro_derive` macro has correct arguments when applied to the crate root](rust-lang/rust#143607) </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:eyJjcmVhdGVkSW5WZXIiOiI0MS4xMTYuNiIsInVwZGF0ZWRJblZlciI6IjQxLjExNi42IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team T-opsem Relevant to the opsem team