-
Notifications
You must be signed in to change notification settings - Fork 4
AssocFn with vtable_receiver #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Btw you may have guessed but you can entirely ignore CI failures in this repo: this is trying to run the same tests as upstream hax but I only care about what affects charon. |
|
Sure, thanks! |
|
Mentioned issues all resolved. |
|
Looks good, ty! |
|
This is causing lots of panics, did you test this in charon before submitting it? We should not have merged it if it breaks charon. |
|
Found a fix. |
|
The original version (before the is_vtable_safe_method) works well with the PR AeneasVerif/charon#814 . But the later versions are not tested. I’m away from the office now. |
|
It was indeed an incorrect invocation of |
|
Sorry about that and thanks for the fix! |
This is to work with AeneasVerif/charon#814 . With the
vtable_safe(bool) changed tovtable_receiver(Option<Ty>), theVtableMethodis now free from theTyparameters.