Unable to perform code generation on ROS 2 interfaces that use the wstring data type

[JohnTGZ]

Hi! First of all thanks for this package, I have been trying out the examples successfully.
However, if I extend example_package/build.rs that perform code generation on installed ROS packages:

    let custom_message_paths: Vec<std::path::PathBuf> = vec![
        "/opt/ros/kilted".into(),
    ];

    let (source, dependent_paths) =
        roslibrust::codegen::find_and_generate_ros_messages_without_ros_package_path(
            custom_message_paths,
        )?;

I got the following error indicating that there is no support for wstring as of now:

  Error: SimpleError { err: "No Rust type for wstring" }

Is this expected? I saw that code generation for wstring data type might not be have implemented.
If so, what are some steps that might need to be done to enable wstring support?

[Carter12s]

Thanks for filing this issue! You are correct that wstring is broken currently and we need to expand support for it.

There are some things we need to figure out before I can give you a good answer on wstring support:

• How does ros2's rosbridge_server encode wstring to and from JSON, we need whatever type we use to work with that
• If a user tries to use a wstring message with ROS1 what should happen? Is there a safe / sane fallback or should we return an Err?

Doing some research:

• There is an open issue on ros1_bridge for solving this problem. Which indicates that when bridging ROS1 <-> ROS2 we should try make it a String and do automatic UTF-16 -> UTF-8 conversion.
• The ROS2 design calls out how complicated this is, and why ROS 2 uses std::u16string instead of std::wstring

I think the "ideal solution" looks something like:

• We have to define our own type Ros2WString(String)
• We have to define custom serialization logic for it depending on the destination type (ROS1 different than ROS2), which we currently don't have any infrastructure fore
• We may ALSO have to do something custom for rosbridge depending on what its authors chose to do
• We have to make some nice utilities to make our Ros2WString type easy to work with.

That being said, in the meantime we might be able to cheat and use Vec as the type and get something working even if it had nasty ergonomics.

tl;dr ROS2 wstring is one of the things that make inter-compatibility hard, and nobody seems to have solved this one yet.

P.S. A workaround for all of this could be to start tagging generated messages with a Ros1Message trait, or a Ros2Message trait, and get compile time failures for "You attempted to use a ROS2 only message with a ROS1 backend," but it would be cool if we could make compatibility actually work.