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 https://github.com/CQCL/hugr/issues/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
commented
3 months ago
We use the
typetagcrate to manage serialisation and deserialisation ofdyn CustomConstvalues. When deserialisation of adyn CustomConstfails, we are not able to distinguish between: 1) Theimpl CustomConstis not linked into the current program, so the typetag handler for that type is not present 2) The serialisation of the knownimpl CustomConstwas invalid. (e.g. see https://github.com/CQCL/hugr/issues/1091)Currently we do not fail to deserialise, and store a
CustomSerializedin the Hugr.We should fail to deserialise in the 2) case, and continue to succeed with a
CustomSerializedin the 1) case.typetagdoes not offer any facility to distinguish these cases. I see three options:typetag. It's unclear whether it would be accepted.typetag::serde(e.g.hugr::custom_const::serde) that add this feature. This could be done by registering aninventoryof 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.Serialize + for<'a> Deserialize<'a>to super traits ofCustomConst. Thread&ExtensionRegistrythrough where it is needed. remove#[cfg(not(miri))]on tests that typetag breaks.