add ptr getter method

[robamu]

I think I used this to verify the correctness of the pointer offset for a generic HAL API.

[robamu]

Oh, a MSRV problem, and you suggested a tool that solves this I think...

[robamu]

This is odd. Apparently, on older Rust compiler, I am leaking a private type. I just wonder why this is not an issue on newer versions of Rustc

[robamu]

Okay, this has a caveat: The generated code now required the rustversion dependency. This can be documented, similarly to how svd2rust documents the required dependencies of the generated code. This would allow the derive mmio crate to add new features with a higher MSRV without actually having to bump the MSRV. What do you think?

[jonathanpallant]

Oh, is this because it's a pub function that returns a type that might not be pub?

[jonathanpallant]

Maybe this API should be hidden behind an attribute, people can generate code that doesn't use rustversion if they prefer?

I'm still confused why it was OK in 1.74.1 but not in 1.74 in 1.74 but not in 1.73.

Maybe related to https://blog.rust-lang.org/2023/11/16/Rust-1.74.0.html?

[jonathanpallant]

Lukas suggests:

let vis = &input.vis;
...
quote! {

            /// Retrieve the base pointer for this MMIO handle.
            #[inline]
            $vis const unsafe fn ptr(&self) -> *mut #ident {
                self.ptr
            }
}

[robamu]

I see you already created an issue in rust-lang/rust#138982 which might explain this

[jonathanpallant]

Well they say "yes, we changed how the errors are reported".

So we probably need to control whether the function is public based on whether the return type is public.

[robamu]

The suggestion by Lukas worked.. I think this might be the best fix. About the rustversion dependency: With this,
the field pointer getters (#25 (comment)) could be made const again, hidden behind a #[rustversion::attr(since(1.83), const)] . But I think this is a separate PR now.

[jonathanpallant]

Thank you!

[robamu]

Oh, I think an unneded dependency slipped in