transmute_unchecked contracts and harnesses

[AlexLB99]

This is a pull request towards solving #19.

Changes

• Added wrappers for transmute_unchecked()
• Annotated these wrappers with contracts
• Wrote harnesses that verify these wrappers

Note: the reason we write wrappers for transmute_unchecked() and we annotate those wrappers is that function contracts do not appear to be currently supported for compiler intrinsics (as discussed in #3345). Also, rather than using a single wrapper for transmute_unchecked(), we write several with different constraints on the input (since leaving the function parameters completely generic severely restricts what we can do in the contracts, e.g., testing for equality).

This is not intended to be a complete solution for verifying transmute_unchecked(), but instead a proof of concept to see how aligned this is with the expected solution. Any feedback would be greatly appreciated -- thank you!

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

[patricklam]

hi @celinval and @feliperodri! Thoughts most welcome.

[tautschnig]

Can the CI failures please be addressed?

[patricklam]

I guess that we can't trigger the workflow @tautschnig

[tautschnig]

You might unintentionally have reverted submodule changes?

[patricklam]

Is it supposed to say "this workflow requires approval from a maintainer"?

[AlexLB99]

You might unintentionally have reverted submodule changes?

I believe the issue may have been a merge conflict caused by a recent upstream commit that moved intrinsic.rs (which is the file being modified here) to another location. I think in theory the problem should be fixed now @tautschnig

[tautschnig]

Is it supposed to say "this workflow requires approval from a maintainer"?

Yes, we have opted for those rules out of caution.

[tautschnig]

You might unintentionally have reverted submodule changes?

It looks like those are still present.

[AlexLB99]

You might unintentionally have reverted submodule changes?

It looks like those are still present.

Ah yes I see what you meant, it looks like there were some changes to library/stdarch. I've reverted those changes, so I think everything should be good to go now 👍

[patricklam]

@tautschnig can we get the ci to run?

[tautschnig]

@tautschnig can we get the ci to run?

CI run has been approved and is in progress.

[patricklam]

Requesting a review again...

[tautschnig]

@AlexLB99 Was closing this PR an intentional act?

[AlexLB99]

@AlexLB99 Was closing this PR an intentional act?

Yes, temporarily -- I was resolving some merge conflicts (so I started by deleting the previous commits, which automatically closes the pr). I also pushed some new changes to reflect the previous comments.

[AlexLB99]

Hi, I'm just following up to see if anyone would be able to review this pr, to see if everything is on the right track (@celinval or anyone else interested). Thanks in advance!

[celinval]

It looks much better. I think the main adjustment is to add a value validity clause as a pre-condition.

[celinval]

Be aware that the value validity check is not currently enabled in this repository.

[AlexLB99]

Be aware that the value validity check is not currently enabled in this repository.

Thanks for the reviews! Just to clarify, do you mean here that -Z valid-value-checks is not enabled by default, or that the can_dereference precondition is not actually checking value validity (or something else)?

[celinval]

Be aware that the value validity check is not currently enabled in this repository.

Thanks for the reviews! Just to clarify, do you mean here that -Z valid-value-checks is not enabled by default, or that the can_dereference precondition is not actually checking value validity (or something else)?

The former. -Z valid-value-checks is not enabled by default.

[AlexLB99]

I pushed a commit that just added a note about the potential bug we discussed. At this stage, should we consider merging what we have so far (pending any immediate suggestions), or would it be better to continue adding stuff here? In either case, I think the next steps on our end might be to dive a bit deeper into pointers and references (and of course, please feel free to let me know if there's anything in particular that you would like us to assign a greater priority to). Thanks!

[celinval]

Looks good to me. Let's get a second reviewer so we can merge this.

[AlexLB99]

I've created a commit that addressed the previous comments. The main things are that I added macros for the suggested harnesses (as well as for the 2-way transmute harnesses). I also removed the padding-related harnesses, since it's not clear at the moment how we'd write a meaningful proof for that (i.e., we can generate many different structs with macros, but even then it wouldn't be a complete proof -- we'll probably put these aside for now while we think of a better way to approach this). Please let me know if you have any further suggestions @feliperodri -- thanks!

[patricklam]

Thanks. Are we good to merge?

…

On Tue, Feb 4, 2025, 4:47 p.m. Felipe R. Monteiro ***@***.***> wrote: ***@***.**** approved this pull request. — Reply to this email directly, view it on GitHub <#185 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOKE5XS5X6NWVMXXESWYF32OEYPPAVCNFSM6AAAAABSO4NMBGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKOJUGEZTSNJXGA> . You are receiving this because you commented.Message ID: ***@***.***>