Various improvements to VirtAddr and PhysAddr.

[m-ou-se]

VirtAddr::new_unchecked didn't behave like the new_unchecked functions in core which just wrap the value without checks or modifications, but instead behaved like PhysAddr::new_truncate. This change renames it to new_truncate, and adds unsafe new_unchecked new_unsafe functions.

Unfortunately, that does mean it's a breaking change. However, I think following this convention for "unchecked" is important to not cause confusion:

• When looking for something that fixes/truncates the address, I couldn't find any function that did that. (I didn't think that new_unchecked would do that.)
• When looking for something that lets me unsafely wrap an address, I used new_unchecked, and was surprised by the compiler warning that the unsafe block was unnecessary.

Also fixes and adds some other small things.

[phil-opp]

Thanks a lot! I fully agree with your reasoning. However, I don't think that it's a good idea to use the same new_unchecked name for the new function because it could silently break user's code. For example, if the new_unchecked function was used inside an unsafe block (or an unsafe fn), the behavior silently changes without any compile time error. So I think a different name would be better to ensure that a compile-time error occurs.

[m-ou-se]

Sure. Any suggestions? new_unsafe, or something else? Do you want to keep the old new_unchecked as #[deprecated]?

[phil-opp]

I don't have any good ideas, but new_unsafe seems fine.

Do you want to keep the old new_unchecked as #[deprecated]?

That's a good idea!

[m-ou-se]

Updated. Now it's no longer a breaking change.

[phil-opp]

Thank you!

[phil-opp]

Given that this still involves some churn for users, I would like to release it as a new semver-incompatible version, preferable together with some other breaking changes that I want to make. This might take a few days, I hope this is fine with you.