Skip to content

Rollup of 11 pull requests #144208

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 30 commits into from
Jul 20, 2025
Merged

Rollup of 11 pull requests #144208

merged 30 commits into from
Jul 20, 2025

Conversation

matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Jul 20, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

GuillaumeGomez and others added 30 commits July 16, 2025 14:27
This should have used build-pass rather than check-pass.
This is no longer implied by -wasm-enable-eh.
The presence of `@add-core-stubs` indicates that this was already
intended.
According to
https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303/4,
LLVM allows volatile operations on null and handles it correctly. This
should be allowed in Rust as well, because I/O memory may be hard-coded
to address 0 in some cases, like the AVR chip ATtiny1626.

A test case that ensured a failure when passing null to volatile was
removed, since it's now valid.

Due to the addition of `maybe_is_aligned` to `ub_checks`,
`maybe_is_aligned_and_not_null` was refactored to use it.

docs: revise restrictions on volatile operations

A distinction between usage on Rust memory vs. non-Rust memory was
introduced. Documentation was reworded to explain what that means, and
make explicit that:

- No trapping can occur from volatile operations;
- On Rust memory, all safety rules must be respected;
- On Rust memory, the primary difference from regular access is that
  volatile always involves a memory dereference;
- On Rust memory, the only data affected by an operation is the one
  pointed to in the argument(s) of the function;
- On Rust memory, provenance follows the same rules as non-volatile
  access;
- On non-Rust memory, any address known to not contain Rust memory is
  valid (including 0 and usize::MAX);
- On non-Rust memory, no Rust memory may be affected (it is implicit
  that any other non-Rust memory may be affected, though, even if not
  referenced by the pointer). This should be relevant when, for example,
  reading register A causes a flag to change in register B, or writing
  to A causes B to change in some way. Everything affected mustn't be
  inside an allocation.
- On non-Rust memory, provenance is irrelevant and a pointer with none
  can be used in a valid way.

fix: don't lint null as UB for volatile

Also remove a now-unneeded `allow` line.

fix: additional wording nits
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)
… r=RalfJung

Stabilize `const_float_round_methods`

Closes rust-lang#141555, waiting for FCP.
…lbinarycat

[rustdoc] Make aliases search support partial matching

Fixes rust-lang#140782.

To make this work, I moved aliases into the `searchIndex` like any other item. It links to the "original" item with a new `original` field. No so great part is that we need to have some fields like `bitIndex` to be set on the alias to make the description load to work but I consider it minor enough to be ok.

This PR voluntarily doesn't handle de-prioritization of aliases as ```@lolbinarycat``` wished to work on this so I'll leave them this part. 😉

cc ```@lolbinarycat```
Fix debuginfo-lto-alloc.rs test

This should have used build-pass rather than check-pass.
…d, r=jhpratt

Remove deprecated `MaybeUninit` slice methods

These were left in to make migration a bit easier, although they should be removed now since they were never stable.
Fixes for LLVM 21

This fixes compatibility issues with LLVM 21 without performing the actual upgrade. Split out from rust-lang#143684.

This fixes three issues:
 * Updates the AMDGPU data layout for address space 8.
 * Makes emit-arity-indicator.rs a no_core test, so it doesn't fail on non-x86 hosts.
 * Explicitly sets the exception model for wasm, as this is no longer implied by `-wasm-enable-eh`.
…=Mark-Simulacrum

Cleanup unicode table gen

Fixing clippy warnings and moving to edition 2024.
Add implicit sized bound to trait ascription types

r? ```@fmease``` or reassign

Thanks for catching this :)

Fixes rust-lang#144135
…r=lqd

Remove pretty print hack for async blocks

I introduced this hack 3 years ago, but it's not needed anymore, probably due to rust-lang#104321.
interpret: fix TypeId pointers being considered data pointers

Fixes rust-lang/miri#4477
r? ````@oli-obk````
@rustbot rustbot added A-CI Area: Our Github Actions CI A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-rustdoc-search Area: Rustdoc's search feature A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. rollup A PR which is a rollup labels Jul 20, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jul 20, 2025

📌 Commit faefaa0 has been approved by matthiaskrgr

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 20, 2025
@bors
Copy link
Collaborator

bors commented Jul 20, 2025

⌛ Testing commit faefaa0 with merge ca9eecd...

@bors
Copy link
Collaborator

bors commented Jul 20, 2025

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing ca9eecd to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 20, 2025
@bors bors merged commit ca9eecd into rust-lang:master Jul 20, 2025
12 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 20, 2025
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 81af9d4 (parent) -> ca9eecd (this PR)

Test differences

Show 235 test diffs

Stage 1

  • [ui] tests/ui/impl-trait/in-bindings/implicit-sized.rs: [missing] -> pass (J1)
  • [ui] tests/ui/precondition-checks/read_volatile.rs#null: pass -> [missing] (J1)
  • [ui] tests/ui/precondition-checks/write_volatile.rs#null: pass -> [missing] (J1)

Stage 2

  • [ui] tests/ui/impl-trait/in-bindings/implicit-sized.rs: [missing] -> pass (J0)
  • [ui] tests/ui/precondition-checks/read_volatile.rs#null: pass -> [missing] (J0)
  • [ui] tests/ui/precondition-checks/write_volatile.rs#null: pass -> [missing] (J0)
  • [run-make] tests/run-make/compressed-debuginfo-zstd: ignore (ignored if LLVM wasn't build with zstd for ELF section compression (we want LLVM/LLD to be built with zstd support)) -> pass (J2)

Additionally, 228 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard ca9eecda36795789511e6e19500cb13b5a053fec --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-apple-various: 7523.0s -> 5384.0s (-28.4%)
  2. pr-check-1: 2119.4s -> 1550.2s (-26.9%)
  3. x86_64-rust-for-linux: 3449.4s -> 2633.5s (-23.7%)
  4. test-various: 5696.8s -> 4591.8s (-19.4%)
  5. pr-check-2: 2734.6s -> 2205.7s (-19.3%)
  6. aarch64-apple: 4952.0s -> 4030.3s (-18.6%)
  7. x86_64-gnu-tools: 4319.3s -> 3522.0s (-18.5%)
  8. x86_64-gnu-aux: 7294.9s -> 6024.2s (-17.4%)
  9. arm-android: 6928.5s -> 5781.1s (-16.6%)
  10. x86_64-gnu-miri: 5623.3s -> 4749.2s (-15.5%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#141260 Allow volatile access to non-Rust memory, including address… f91f285fc9ac551f1d1e4343dffde04954712051 (link)
#143604 Stabilize const_float_round_methods 0db500d44ba41bdd726d0b715ab6d7f53506e97c (link)
#143988 [rustdoc] Make aliases search support partial matching ff8fbb95489c490145630ac21f89c11818acfdf7 (link)
#144078 Fix debuginfo-lto-alloc.rs test 932832affe9110795148b9236b21602cc3ccf59f (link)
#144111 Remove deprecated MaybeUninit slice methods 3ebfb6889b3ff035f76f0143a93ce1bcd8a5a202 (link)
#144116 Fixes for LLVM 21 6a39d135886f65576f06551059bfb1ea301bbc8a (link)
#144134 Cleanup unicode table gen 327f7299efea532f8fdc3606bf4b2075f1017d37 (link)
#144142 Add implicit sized bound to trait ascription types 2fe19730991c9ef04a6629355e6f644a70396592 (link)
#144148 Remove pretty print hack for async blocks 111bf06dfd684b1def1892d92faeabd779f2e5ed (link)
#144169 interpret: fix TypeId pointers being considered data pointe… 0a70f74335ab01c80836d06985f34cd803f37f5a (link)
#144196 Initialize mingw for the runner's user 710ccfc4837f02311f6c38e125f8bc86361bca68 (link)

previous master: 81af9d4569

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (ca9eecd): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 1.3%, secondary 3.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
1.3% [1.3%, 1.3%] 1
Regressions ❌
(secondary)
3.2% [0.9%, 4.8%] 3
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.3% [1.3%, 1.3%] 1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary 0.0%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.0%] 8
Regressions ❌
(secondary)
0.0% [0.0%, 0.0%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [0.0%, 0.0%] 8

Bootstrap: 465.3s -> 465.087s (-0.05%)
Artifact size: 374.58 MiB -> 374.54 MiB (-0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-CI Area: Our Github Actions CI A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-rustdoc-search Area: Rustdoc's search feature A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.
Projects
None yet
Development

Successfully merging this pull request may close these issues.