| 09808839 | 19-Mar-2026 |
Antonio Hickey <contact@antoniohickey.com> |
rust: pin-init: replace `addr_of_mut!` with `&raw mut`
`feature(raw_ref_op)` became stable in Rust 1.82.0 which is the current MSRV of pin-init with no default features. Earlier Rust versions will n
rust: pin-init: replace `addr_of_mut!` with `&raw mut`
`feature(raw_ref_op)` became stable in Rust 1.82.0 which is the current MSRV of pin-init with no default features. Earlier Rust versions will now need to enable `raw_ref_op` to continue to work with pin-init.
This reduces visual complexity and improves consistency with existing reference syntax.
Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1148 Closes: https://github.com/Rust-for-Linux/pin-init/issues/99 Signed-off-by: Antonio Hickey <contact@antoniohickey.com> Link: https://github.com/Rust-for-Linux/pin-init/commit/e27763004e2f6616b089437fbe9b3719cd72bd5c [ Reworded commit message. - Benno ] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260319093542.3756606-6-lossin@kernel.org Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 960c37cb | 19-Mar-2026 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: properly document let binding workaround
The three let bindings (in the bodies of `cast_init`, `cast_pin_init` and the `init!` macro) are used to avoid the following compiler error i
rust: pin-init: properly document let binding workaround
The three let bindings (in the bodies of `cast_init`, `cast_pin_init` and the `init!` macro) are used to avoid the following compiler error in Rust 1.78.0, 1.79.0, 1.80.0, 1.80.1, and 1.81.0 (just showing the one for `cast_init`, the others are similar):
error[E0391]: cycle detected when computing type of opaque `cast_init::{opaque#0}` --> src/lib.rs:1160:66 | 1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> { | ^^^^^^^^^^^^^^^ | note: ...which requires borrow-checking `cast_init`... --> src/lib.rs:1160:1 | 1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: ...which requires const checking `cast_init`... --> src/lib.rs:1160:1 | 1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: ...which requires computing whether `cast_init::{opaque#0}` is freeze... = note: ...which requires evaluating trait selection obligation `cast_init::{opaque#0}: core::marker::Freeze`... = note: ...which again requires computing type of opaque `cast_init::{opaque#0}`, completing the cycle note: cycle used when computing type of `cast_init::{opaque#0}` --> src/lib.rs:1160:66 | 1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> { | ^^^^^^^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information
Once we raise the nightly-MSRV above 1.81, we can remove this workaround.
Link: https://github.com/Rust-for-Linux/pin-init/commit/bb3e96f3e9a4f5fca80a22af883c7e5aa90f0893 [ Moved this commit after the previous one to avoid a build failure due to unstable features. Changed the cfg to use `USE_RUSTC_FEAUTURES`. - Benno ] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260319093542.3756606-3-lossin@kernel.org Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| fc3870dc | 05-Jun-2025 |
Benno Lossin <lossin@kernel.org> |
rust: pin-init: examples, tests: use `ignore` instead of conditionally compiling tests
Change `#[cfg(cond)]` to `#[cfg_attr(not(cond), ignore)]` on tests.
Ignoring tests instead of disabling them s
rust: pin-init: examples, tests: use `ignore` instead of conditionally compiling tests
Change `#[cfg(cond)]` to `#[cfg_attr(not(cond), ignore)]` on tests.
Ignoring tests instead of disabling them still makes them appear in the test list, but with `ignored`. It also still compiles the code in those cases.
Some tests still need to be ignore, because they use types that are not present when the condition is false. For example the condition is `feature = std` and then it uses `std::thread::Thread`.
Suggested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/all/aDC9y829vZZBzZ2p@google.com Link: https://github.com/Rust-for-Linux/pin-init/pull/58/commits/b004dd8e64d4cbe219a4eff0d25f0a5f5bc750ca Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Link: https://lore.kernel.org/all/20250605155258.573391-1-lossin@kernel.org Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 2408678d | 23-May-2025 |
Benno Lossin <benno.lossin@proton.me> |
rust: pin-init: examples: pthread_mutex: disable the main test for miri
`miri` takes a long time to execute the test, so disable it.
Link: https://github.com/Rust-for-Linux/pin-init/pull/50/commits
rust: pin-init: examples: pthread_mutex: disable the main test for miri
`miri` takes a long time to execute the test, so disable it.
Link: https://github.com/Rust-for-Linux/pin-init/pull/50/commits/e717a9eec85024c11e79e8bd9dcb664ad0de8f94 Link: https://lore.kernel.org/all/20250523125424.192843-3-lossin@kernel.org Signed-off-by: Benno Lossin <lossin@kernel.org>
show more ...
|
| 39051adb | 14-Apr-2025 |
Benno Lossin <benno.lossin@proton.me> |
rust: pin-init: examples: use `allow` instead of `expect`
Rust 1.78 doesn't emit a `dead_code` error on the annotated element, resulting in the `unfulfilled_lint_expectations` error. Rust 1.85 does
rust: pin-init: examples: use `allow` instead of `expect`
Rust 1.78 doesn't emit a `dead_code` error on the annotated element, resulting in the `unfulfilled_lint_expectations` error. Rust 1.85 does emit the `dead_code` error, so we still need an `allow`.
Link: https://github.com/Rust-for-Linux/pin-init/pull/33/commits/0e28cbb895bd29f896a59b40e8ed506ea7bef13c Link: https://lore.kernel.org/all/20250414195928.129040-4-benno.lossin@proton.me Signed-off-by: Benno Lossin <benno.lossin@proton.me>
show more ...
|