-
Notifications
You must be signed in to change notification settings - Fork 13.6k
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
Rollup of 11 pull requests #144208
Conversation
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````
Initialize mingw for the runner's user This is apparently the more proper fix to https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Spurious.20bors.20CI.20failures/near/528915775 But let's see if it works.
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
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 differencesShow 235 test diffsStage 1
Stage 2
Additionally, 228 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard ca9eecda36795789511e6e19500cb13b5a053fec --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
📌 Perf builds for each rolled up PR:
previous master: 81af9d4569 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (ca9eecd): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (primary 0.0%, secondary 0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 465.3s -> 465.087s (-0.05%) |
Successful merges:
const_float_round_methods
#143604 (Stabilizeconst_float_round_methods
)MaybeUninit
slice methods #144111 (Remove deprecatedMaybeUninit
slice methods)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup