If you set ctor_convention to "uses-leading-allocator" in the configuration yaml it only partially correct. Fields get correctly initialized with leading-allocator construction but the message classes themselves still use trailing-allocator construction. This means if you nest one message in another it will break as the field for the nested message gets initialized with leading-allocator construction but its message class is still trailing-allocator construction.
We might need two properties, one to specify the convention of the message class and another to specify the convention for variable length array. Maybe "ctor_convention" and "variable_array_type_ctor_convention".
To support this well the verification/CMakeLists.txt probably needs to be reworked. Looks like right now it only supports configurations as specified by the .vscode/cmake-variants.json. Not sure if we want to add another variant for leading-constructor. Feels like this head towards combinatorial explosion as there may be other configuration yamls we might want to test. Probably needs a bit of thought here.
If you set ctor_convention to "uses-leading-allocator" in the configuration yaml it only partially correct. Fields get correctly initialized with leading-allocator construction but the message classes themselves still use trailing-allocator construction. This means if you nest one message in another it will break as the field for the nested message gets initialized with leading-allocator construction but its message class is still trailing-allocator construction.
We might need two properties, one to specify the convention of the message class and another to specify the convention for variable length array. Maybe "ctor_convention" and "variable_array_type_ctor_convention".
To support this well the verification/CMakeLists.txt probably needs to be reworked. Looks like right now it only supports configurations as specified by the .vscode/cmake-variants.json. Not sure if we want to add another variant for leading-constructor. Feels like this head towards combinatorial explosion as there may be other configuration yamls we might want to test. Probably needs a bit of thought here.