Files generated with FastDDSGen not correct

[borkhuis-cnh]

Hello,

I am having some issues with FastDDSGen. I am upgrading from FastDDS 2.14.4 to 3.2.2 and for that we also need the latest version of FastDDSGen (version 4.0.4).
With the older version the generated files are correct but with the new version I see some strange things.
The IDL files I am using are:
simple.idl:

module test
{
    module nested_test
    {
        @final
        struct simple
        {
            string str;
        };
    };
};

child.idl:

#include "simple.idl"

module test
{
    @final
    struct child : nested_test::simple
    {
        long long_val;
    };
};

This generates the following code (only partly shown):
simple.hpp:

namespace test {

namespace nested_test {

/*!
 * @brief This class represents the structure simple defined by the user in the IDL file.
 * @ingroup simple
 */
class simple
{

child.hpp:

....
namespace test {

/*!
 * @brief This class represents the structure child defined by the user in the IDL file.
 * @ingroup child
 */
class child : public nested_simple
{
....

However, nested_simple is never defined. The older version of FastDDSGen used public test::nested_test::simple. When I add the line
using nested_simple = test::nested_test::simple;
to the generated child.hpp the code does compile. Is this an issue with FastDDSGen or can I change my IDL files to generate the correct files?

[Mario-DL]

Hi @borkhuis-cnh ,

Since nested is a reserved keyword (annotation) within Fast DDS Gen, please try not to use it as the identifier of the module. Could you please double check with a different nested module name (e.g inner_test) ?

[borkhuis-cnh]

Hello @Mario-DL ,

Thank you for the reply, that did indeed fix the issue with FastDDSGen.
Is there a list of reserved words that we should avoid in IDL files?

Regards,
Johan

[Mario-DL]

For the sake of completeness, here you can find the list of builtn annotations. However, we will make Fast DDS Gen to fail compiling in that situation.

[borkhuis-cnh]

Thank you for the list. It took me quite some time before I found out where the issue was and (with your help) solve it. It would indeed have been better if the tool would have failed with an error message, that way I would have know where to look. So that would be a good improvement.