Skip to content
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

In serialisation we do not distinguish between unknown CustomConst serialised value invalid but known CustomConst serialised values #1225

Open
doug-q opened this issue Jun 25, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@doug-q
Copy link
Collaborator

doug-q commented Jun 25, 2024

We use the typetag crate to manage serialisation and deserialisation of dyn CustomConst values. When deserialisation of a dyn CustomConst fails, we are not able to distinguish between:

  1. The impl CustomConst is not linked into the current program, so the typetag handler for that type is not present
  2. The serialisation of the known impl CustomConst was invalid. (e.g. see Invalid constants can pass validation #1091)

Currently we do not fail to deserialise, and store a CustomSerialized in the Hugr.

We should fail to deserialise in the 2) case, and continue to succeed with a CustomSerialized in the 1) case.

typetag does not offer any facility to distinguish these cases. I see three options:

  • Attempt to parse the deserialisation error message.
  • Attempt to contribute this feature to typetag. It's unclear whether it would be accepted.
  • Write (proc-macro) wrappers for typetag::serde (e.g. hugr::custom_const::serde) that add this feature. This could be done by registering an inventory of type names (as typetag does) in parallel, and and inspecting this during serialisation, and failing in a detectable way if deserialisation of the content failed when the tag is present in our inventory.
  • abandon typetag. Extensions declare their Consts. add Serialize + for<'a> Deserialize<'a> to super traits of CustomConst. Thread &ExtensionRegistry through where it is needed. remove #[cfg(not(miri))] on tests that typetag breaks.
@doug-q doug-q added the bug Something isn't working label Jun 25, 2024
github-merge-queue bot pushed a commit that referenced this issue Jun 25, 2024
Fixes #1185. We add a test for #1091, but the fix unclear now, see
#1225.

---------

Co-authored-by: Douglas Wilson <[email protected]>
@doug-q
Copy link
Collaborator Author

doug-q commented Jun 26, 2024

See dtolnay/typetag#79

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant