CQCL/hugr

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

Opened this issue · 1 comments

doug-q commented

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 #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.