Add old rustc support as feature

[Voultapher]

fixes #31

This provides polyfilled support for addr_of_mut for older rustc versions. This required splitting the tests, but has the benefit of sliming down the main test dependencies.

This also documents the version requirements and tests them in the CI.

[Voultapher]

@mitsuhiko please let me know if this addresses your issue.

[mitsuhiko]

@Voultapher would you be open to the idea of adding rustversion as a dependency for old_rust? I'm a bit worried that Rust will start optimizing this and there is then no way to turn off this feature. Other than that, this absolutely would fix my issue.

[Voultapher]

Good point, this transitively affects library users, who can't control what their users compile with. I'll look at a solution. The most straightforward thing would be to use rustversion with 3 versions of the macro.

[mitsuhiko]

I believe given how rustversion is structured and the fact that attributes cannot be placed on these macro rules, this is probably the shortest you can get away with

#[doc(hidden)]
#[macro_export]
#[cfg(feature = "old_rust")]
#[rustversion::before(1.51)]
macro_rules! _addr_of_mut {
    ($expr:expr) => {
        &mut $expr as *mut _
    };
}

#[doc(hidden)]
#[macro_export]
#[cfg(feature = "old_rust")]
#[rustversion::since(1.51)]
macro_rules! _addr_of_mut {
    ($expr:expr) => {
        core::ptr::addr_of_mut!($expr)
    };
}

#[doc(hidden)]
#[macro_export]
#[cfg(not(feature = "old_rust"))]
macro_rules! _addr_of_mut {
    ($expr:expr) => {
        core::ptr::addr_of_mut!($expr)
    };
}

[Voultapher]

I just noticed doesn't core::ptr::addr_of_mut!((*joined_ptr.as_ptr()).dependent) here the (*joined_ptr.as_ptr()) already create a reference to uninitialized memory? @steffahn

[Voultapher]

Referencing https://doc.rust-lang.org/core/ptr/macro.addr_of_mut.html

Note, however, that the expr in addr_of_mut!(expr) is still subject to all the usual rules. In particular, addr_of_mut!(*ptr::null_mut()) is Undefined Behavior because it dereferences a null pointer.

[Voultapher]

Looking at prior art, it's a mixed bag https://grep.app/search?q=addr_of_mut%21

• Diesel does use a inner MaybeUninit https://github.com/diesel-rs/diesel/blob/54122fb305daf12d3f05ff174a8024dec6323318/diesel/src/mysql/connection/bind.rs#L376
• Rust BTree node does not use MaybeUninit https://github.com/rust-lang/rust/blob/ff0e14829e1806ca0d4226595f7fdf3e8658758f/library/alloc/src/collections/btree/node.rs#L75
• Rust Rc does use MaybeUninit https://github.com/rust-lang/rust/blob/ff0e14829e1806ca0d4226595f7fdf3e8658758f/library/alloc/src/rc.rs#L417

[Voultapher]

I've pushed a version that implements the current scheme without MaybeUninit, if we conclude that's needed I will update. Note @mitsuhiko your suggested approach didn't work because 'procedural macros cannot expand to macro definitions' at least for rustc 1.36.

[mitsuhiko]

That looks good!

[Voultapher]

@mitsuhiko I've posted the question here https://users.rust-lang.org/t/does-addr-of-mut-require-maybeuninit/66754 and hope I can clarify this soon, and then close this and release a new version. Thanks for the patience.