ndsev / zserio

zero sugar, zero fat, zero serialization overhead
https://zserio.org/
BSD 3-Clause "New" or "Revised" License
109 stars 27 forks source link

Generated code of a struct used within a templated struct depends on existence of instantiations. #663

Open MisterGC opened 2 weeks ago

MisterGC commented 2 weeks ago

The generated code (all supported languages) for a structure differs depending on whether it is used in the scope of a packed array or not. Specifically, the method signature for write() changes, adding or omitting a context parameter related to packaging.

This is especially tricky when dealing with templates that use the struct in the scope of a packed array. As long as the template is not instantiated, the packaging context is not part of the write() method signature, when it gets instantiated (e.g. with a schema update), the packaging context gets added.

// ConditionList only gets the packaging context, if ConditionalValue gets instantiated
struct ConditionalValue<VAL_T>()
{
    VAL_T  value;
    packed ConditionList conditions;
};

Having the packaging context for all structs would be no good solution. But at least the usage in the scope of templates, even without instantiation should always lead to the consistent signature (with the packaging context!?).

Mi-La commented 2 weeks ago

Probably caused by https://github.com/ndsev/zserio/issues/516.

Currently when the template is not instantiated, it doesn't exist in generated code and thus the check if ConditionList is used in a packed array doesn't consider it. I wouldn't call it a bug, but maybe an enhancement could done in this particular use-case of templates.

But still during the schema evolution, the source code will change depending on whether the type is used in a packed array or not. Thus when you start using some struct in a packed array, it will get the "packing" methods generated.

mikir commented 2 days ago

We have added optimizations section into the documentation of the C++ generator to state explicitly that splitting schema into two parts and generating them independently cannot guarantee correct functionality.

The same section has been added into the documentation of the Java and Python generators.