rosidl
rosidl copied to clipboard
ros2
Resulting IDL conflicts with OMG IDL spec
The resulting IDL from the UUID.msg seems to conflict with the IDL spec Section 7.5.3.
I realize there are some expectations from a ROS developer creating MSG files not to have to concern themselves with IDL specs. This is probably the wrong level to deal with this type of conflict. However, I feel it's worth calling this issue out at this level to start the conversation on how to remedy such conflicts since the layers between aren't handling it.
The resulting IDL from UUID.msg is for some of the type support packages (e.g. Connext):
#ifndef __unique_identifier_msgs__msg__uuid__idl__
#define __unique_identifier_msgs__msg__uuid__idl__
module unique_identifier_msgs {
module msg {
module dds_ {
struct UUID_ {
octet uuid_[16];
};
}; // module dds_
}; // module msg
}; // module unique_identifier_msgs
#endif // __unique_identifier_msgs__msg__uuid__idl__
From the spec we shouldn't be using identifiers that differ only in case. That is uuid_ and UUID_ in this case.
Thanks for clarifying.
7.2.3 Identifiers:
IDL identifiers are case insensitive.
together with 7.5.3 Special Scoping Rules for Type Names:
Once a type has been defined anywhere within the scope of a module, interface or value type, it may not be redefined except within the scope of a nested module, interface or value type, or within the scope of a derived interface or value type.
I will move the ticket to ros2/rosidl since ultimately the transformation from .msg should either error out or mangle the name to follow the spec.
(Since it seems to work with various vendors I am not sure how soon this will get any attention though.)
Makes sense. I suspect some vendors are not properly flagging this as a warning or error. However, with broader adoption means that types could be defined with this issue and then it becomes harder to remove. Still I agree that it's a lower priority.
This isn't really a "vendor" issue though, is it? If rosidl is responsible for the .msg -> .idl transformation, then the resulting .idl should be valid according to the OMG (and ISO) IDL specification so it can be used with any tool that consumes IDL even if it's not specific to ROS2 (modeling tools, for example).
Indeed, but the urgency is determined by the fact that it is / is not affecting used tools. Since afaik all RMW impl. work just fine I consider it a lower priority. If you are aware of a tool which has a problem with it that would probably bump the urgency.
Right, I think we're not blocked by it, but only by using a switch on the IDL compiler that allows nonconforming input (@adamsj-oci can confirm).
The other point I was trying to make before is that one advantage of using IDL is that it can be processed by tools outside of the ROS2 system. So someone could be having the problem and we wouldn't know. Perhaps they'd file the issue, or perhaps they would just think that ROS2's IDL is a different "dialect" of IDL.
only by using a switch on the IDL compiler that allows nonconforming input
Can you please state which concrete IDL compiler you are referring to.
We actually use two different IDL compilers (tao_idl and opendds_idl) in different phases. The both indicate the problem.
I would suggest to add a warning about this. It would be great if someone could contribute a pull request for this.