feat: make page types repr(transparent) and range types repr(Rust)

[mkroening]

This PR makes the custom paging range types repr(Rust), as discussed in #581 (review). repr(C) for these types was introduced in 399b3d4.

This PR also makes Page and PhysFrame repr(Rust), since I did not find any code that does not use these types by value and depends on the representation in any way. I can undo that, though, if that undocumented representation is intentional.

[Freax13]

This PR also makes Page and PhysFrame repr(Rust), since I did not find any code that does not use these types by value and depends on the representation in any way. I can undo that, though, if that undocumented representation is intentional.

Let's keep repr(C) for Page and PhysFrame. I can see use-cases for using these in types interfacing with external ABIs. VirtAddr and PhysAddr also both use non-Rust reprs and I think we should keep that for the same reason.

I can't think of a good example for a use-case of storing PageRange/PhysFrameRange in a C struct, but if anyone knows of one and needs this, please speak up.

[mkroening]

Let's keep repr(C) for Page and PhysFrame. I can see use-cases for using these in types interfacing with external ABIs. VirtAddr and PhysAddr also both use non-Rust reprs and I think we should keep that for the same reason.

I see. If that is something we want to support, we should document that guarantee, though, right?

Also in that case, we could make Page and PhysFrame repr(transparent) instead. The difference is that currently, the ABI of the structs is a C struct containing a uint64_t. If we make it transparent, the ABI of the structs would be uint64_t directly, which seems more useful to me.

[Freax13]

Let's keep repr(C) for Page and PhysFrame. I can see use-cases for using these in types interfacing with external ABIs. VirtAddr and PhysAddr also both use non-Rust reprs and I think we should keep that for the same reason.

I see. If that is something we want to support, we should document that guarantee, though, right?

Yes, we should do that.

Also in that case, we could make Page and PhysFrame repr(transparent) instead. The difference is that currently, the ABI of the structs is a C struct containing a uint64_t. If we make it transparent, the ABI of the structs would be uint64_t directly, which seems more useful to me.

I think for a struct with a single (non-ZST) member, there's no difference between the two, but I agree that repr(transparent) feels cleaner.

[mkroening]

I think for a struct with a single (non-ZST) member, there's no difference between the two, but I agree that repr(transparent) feels cleaner.

The memory layout should be the same, but the ABI when passing the types as arguments may be different for certain targets (armv7-a, M68k, mips, and powerpc64, for example): Compiler Explorer

[Freax13]

I think for a struct with a single (non-ZST) member, there's no difference between the two, but I agree that repr(transparent) feels cleaner.

The memory layout should be the same, but the ABI when passing the types as arguments may be different for certain targets (armv7-a, M68k, mips, and powerpc64, for example): Compiler Explorer

I'm learning a lot today :D

[Freax13]

LGTM, thanks!

And a big thanks for all the changes you contributed lately! We appreciate it!