Rollup of 8 pull requests #144177
Closed
Rollup of 8 pull requests #144177
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This should have used build-pass rather than check-pass.
codegen tests typically depend on the raw LLVM IR output and are
sensitive to debuginfo level. So do not apply
`rust.debuginfo-level-tests` for codegen tests.
Before this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
test result: FAILED. 654 passed; 136 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.22s
After this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
NOTE: ignoring `rust.debuginfo-level-tests=2` for codegen tests
test result: ok. 790 passed; 0 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.21s
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)
Fix debuginfo-lto-alloc.rs test This should have used build-pass rather than check-pass.
…=Mark-Simulacrum bootstrap: Ignore `rust.debuginfo-level-tests` for codegen tests As dicussed in rust-lang#61117 (comment), codegen tests typically depend on the raw LLVM IR output and are sensitive to debuginfo level. So do not apply `rust.debuginfo-level-tests` for codegen tests. Before this commit: $ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun test result: FAILED. 654 passed; 136 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.22s After this commit: $ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun NOTE: ignoring `rust.debuginfo-level-tests=2` for codegen tests test result: ok. 790 passed; 0 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.21s ### Run this in CI? Maybe it will make sense to add this to CI later but I think it is too early to do now before more non-codegen tests work with `rust.debuginfo-level-tests=2`.
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`.
…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.
docs: update link to RISC-V and Xtensa installation guide Replace outdated link https://docs.esp-rs.org/book/installation/riscv-and-xtensa.html with the official Espressif documentation at https://docs.espressif.com/projects/rust/book/installation/index.html
Rename `optional-mingw-check-1` to `optional-pr-check-1` I noticed this when doing a `bors2 try` for `mingw`. I also changed it to use the `pr-check-1` image as `mingw-check-1` no longer exists.
interpret: fix TypeId pointers being considered data pointers Fixes rust-lang/miri#4477 r? `@oli-obk`
rustbot
added
A-CI
|
@bors r+ rollup=never p=5 |
bors
removed
the
S-waiting-on-review
bors
added
the
S-waiting-on-bors
|
I'd like the p-critical fix to get in before rollups. |
|
There's a spellcheck error anyway. @bors r- |
bors
added
S-waiting-on-author
rustbot
removed
the
S-waiting-on-author
|
typos save the day! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
rust.debuginfo-level-testsfor codegen tests #144112 (bootstrap: Ignorerust.debuginfo-level-testsfor codegen tests)optional-mingw-check-1tooptional-pr-check-1#144152 (Renameoptional-mingw-check-1tooptional-pr-check-1)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup