refactor to use &raw mut

[antonio-hickey]

Replacing all occurrences of addr_of_mut!(place) with &raw mut place.

This will allow us to reduce macro complexity, and improve consistency with existing reference syntax as &raw mut is similar to &mut making it fit more naturally with other existing code.

[BennoLossin]

I expected the CI to fail and it didn't, turns out I had some wrong configurations there. I fixed it now, could you rebase on top of main?

Also, since I'm synchronizing the commit as-is into the linux repository, could you add a commit description similar to the one you had in the series on the rust-for-linux mailing list? Thanks!

[antonio-hickey]

GitHub closed the PR because I used it's native sync from upstream instead of just rebasing using git like I should've and had to do anyways haha.

[BennoLossin]

The nightly-msrv check failed, we need #![feature(raw_ref_op)] in the examples and tests. This is a bit annoying, since users that rely on versions 1.81 and earlier also need to do that, so we have to document it in the README. Could you add that? Thanks!
The "proper" msrv of the crate is 1.82 (when with no default features), so it's fine for those (since raw_ref_op is stable after 1.82, right?).

[antonio-hickey]

Yea I can fix the examples/tests, and update the README to account for not being stable in the nightly-msrv.

Also yea raw_ref_op went stable in 1.82, so it's fine for 1.82+

[antonio-hickey]

Hey Benno

Any idea why nightly-msrv is still failing?

The errors are still due to "raw address of syntax is experimental"

 error[E0658]: raw address of syntax is experimental
    --> examples/./linked_list.rs:36:9
     |
  36 | /         try_pin_init!(&this in Self {
  37 | |             next: unsafe { Link::new_unchecked(this) },
  38 | |             prev: unsafe { Link::new_unchecked(this) },
  39 | |             pin: PhantomPinned,
  40 | |         }? Infallible)
     | |______________________^

However I've gone through each error thrown and verified it has a conditional to use the raw_ref_op feature.

The files in error:

• examples/./linked_list.rs: 08c7e13#diff-0539c5be3bd9c3dbabcb4c1503ebc77f4afc70048d99ca4eac20a6d91048eccdR6
• examples/mutex.rs: 08c7e13#diff-bf68678001cc1743a6732656566f0823cb87bc0d59f1f1a9a5eda8c674d28e0eR6

[BennoLossin]

You forgot to add one in src/lib.rs and examples/static_init.rs (that one imports the mutex example). This works for me:

diff --git a/examples/static_init.rs b/examples/static_init.rs
index 0e165daa9798..6247cb39d076 100644
--- a/examples/static_init.rs
+++ b/examples/static_init.rs
@@ -3,6 +3,7 @@
 #![allow(clippy::undocumented_unsafe_blocks)]
 #![cfg_attr(feature = "alloc", feature(allocator_api))]
 #![cfg_attr(not(RUSTC_LINT_REASONS_IS_STABLE), feature(lint_reasons))]
+#![cfg_attr(not(RUSTC_RAW_REF_OP_IS_STABLE), feature(raw_ref_op))]
 #![allow(unused_imports)]
 
 use core::{
diff --git a/src/lib.rs b/src/lib.rs
index 8f89e8da7a79..e8ccfb7c3626 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -264,6 +264,7 @@
 //! [Rust-for-Linux]: https://rust-for-linux.com/
 
 #![cfg_attr(not(RUSTC_LINT_REASONS_IS_STABLE), feature(lint_reasons))]
+#![cfg_attr(not(RUSTC_RAW_REF_OP_IS_STABLE), feature(raw_ref_op))]
 #![cfg_attr(
     all(
         any(feature = "alloc", feature = "std"),

[BennoLossin]

Also could you rebase onto main? Thanks!

[antonio-hickey]

Hey Benno,

I rebased onto main again, but failing due to unused struct Error.

  error: struct `Error` is never constructed
    --> examples/error.rs:11:12
     |
  11 | pub struct Error;
     |            ^^^^^
     |
     = note: `-D dead-code` implied by `-D warnings`
     = help: to override `-D warnings` add `#[allow(dead_code)]`
  
  error: could not compile `pin-init` (example "static_init") due to 1 previous error
  warning: build failed, waiting for other jobs to finish...
  error: process didn't exit successfully: `rustup run 1.89 cargo check --all-targets --locked --manifest-path Cargo.toml --no-default-features` (exit status: 101)

I noticed it only fails the rustc 1.89 which was just released a couple days ago, so previous commit's weren't checked against this. I went back to the latest commit on main and ran the same check locally, and it failed as well.

I'd be open to fixing this in a separate PR if you want, either marking the Error struct in the error example with #[allow(dead_code) or potentially expanding the example to use the Error struct.
Any thoughts on this?

Thanks

[BennoLossin]

Oh interesting... That's a new failure and I wonder why the nightly CI workflow didn't catch it... I have some other CI updates that I'll want to do next week, so I'll add this one to the list. Thanks for the heads-up!

[BennoLossin]

Hey @antonio-hickey do you intend to update this PR & continue working on this, or can we close it?

[antonio-hickey]

Hey @antonio-hickey do you intend to update this PR & continue working on this, or can we close it?

Yea I'll rebase this later tonight and see what needs to be done

[BennoLossin]

Oh no rush, just wanted to make sure we get this in the next cycle, so it would be great if you could update the PR in the next weeks.

[antonio-hickey]

Hey Benno,

I rebased and fixed some stuff to pass tests, only failing the expected error outputs in ui-tests.
It seems like I need to overwrite this stderr output, but figured I'd get your input first.

Thanks

[BennoLossin]

Thanks for the quick work! If you have time, could you try #102 and build upon that to see if it makes things easier (it's best if it's a new PR to better compare the approach)?

If you don't have time for that, don't worry, I'll do it & port your commits over to that. This has been going on for way too long, sorry about that!

[antonio-hickey]

Thanks for the quick work! If you have time, could you try #102 and build upon that to see if it makes things easier (it's best if it's a new PR to better compare the approach)?

If you don't have time for that, don't worry, I'll do it & port your commits over to that. This has been going on for way too long, sorry about that!

Yea, I'll submit a new PR and compare it against this one.

Of course no rush, but just for rough time estimates it should be a couple days.