Skip to content

Rollup of 4 pull requests #141462

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

Closed
wants to merge 9 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ehuss and others added 9 commits May 15, 2025 19:59
This updates some doctests that fail to run on wasm. We will soon be
supporting cross-compiled doctests, and the test-various job fails to
run these tests. These tests fail because wasm32-wasip1 does not support
threads.
For aarch64-apple and aarch64-windows, platform docs state that code
must use frame pointers correctly. This is because the AAPCS64 mandates
that a platform specify its frame pointer conformance requirements:
- Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers
- Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers
- AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer

Unwinding code either requires unwind tables or frame pointers, and
on aarch64 the expectation is that one can use frame pointers for this.
Most Linux targets represent a motley variety of possible distributions,
so it is unclear who to defer to on conformance, other than perhaps Arm.
In the absence of a specific edict for a given aarch64-linux target,
Rust will assume aarch64-linux targets use non-leaf frame pointers.
This reflects what compilers like clang do.
`CStringArray` contained both `CString`s and their pointers. Unfortunately, since `CString` uses `Box`, moving the `CString`s into the `Vec` can (under stacked borrows) invalidate the pointer to the string, meaning the resulting `Vec<*const c_char>` was, from an opsem perspective, unusable. This PR removes removes the `Vec<CString>` from `CStringArray`, instead recreating the `CString`/`CStr` from the pointers when necessary. Also,`CStringArray` is now used for the process args as well, the old implementation was suffering from the same kind of bug.
std: fix aliasing bug in UNIX process implementation

`CStringArray` contained both `CString`s and their pointers. Unfortunately, since `CString` uses `Box`, moving the `CString`s into the `Vec` can (under stacked borrows) invalidate the pointer to the string, meaning the resulting `Vec<*const c_char>` was, from an opsem perspective, unusable. This PR removes removes the `Vec<CString>` from `CStringArray`, instead recreating the `CString`/`CStr` from the pointers when necessary. Also,`CStringArray` is now used for the process args as well, the old implementation was suffering from the same kind of bug.
…d-use-frame-pointers, r=compiler-errors

aarch64-linux: Default to FramePointer::NonLeaf

For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements:
- Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers
- Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers
- AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer

Unwinding code either requires unwind tables or frame pointers, and on aarch64 the expectation is that one can use frame pointers for this. Most Linux targets represent a motley variety of possible distributions, so it is unclear who to defer to on conformance, other than perhaps Arm. In the absence of a specific edict for a given aarch64-linux target, Rust will assume aarch64-linux targets also use non-leaf frame pointers. This reflects what compilers like clang do.
…k-Simulacrum

Updated std doctests for wasm

This updates some doctests that fail to run on wasm. We will soon be supporting cross-compiled doctests, and the test-various job fails to run these tests. These tests fail because wasm32-wasip1 does not support threads.
…crum

Update mdbook to 0.4.50

This updates mdbook to 0.4.50 which brings in several changes, and specifically a fix for syntax highlighting in rust-by-example.

Changelog: https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0450
@rustbot rustbot added 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-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 23, 2025
@rustbot rustbot added the rollup A PR which is a rollup label May 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup 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-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants