tools/nxstyle: Whitelist lifecycle_msgs GetState/State identifiers.

[arjav1528]

Summary

Phase 8 of the micro-ROS on NuttX integration adds GetState service serverand client examples under apps/examples/microros_{srv,cli} (paired apps PR). The rosidl token-pasting macros generate identifiers such as:

lifecycle_msgs__srv__GetState_Request
lifecycle_msgs__srv__GetState_Response
lifecycle_msgs__msg__State__PRIMARY_STATE_ACTIVE
ROSIDL_GET_SRV_TYPE_SUPPORT(lifecycle_msgs, srv, GetState)
rosidl_runtime_c__String__assign

CamelCase tokens (GetState, State, String) cannot be renamed without breaking the public ROS C client API. Adds them, the lifecycle_msgs package prefix, and the rosidl_runtime_c runtime prefix to the existing g_white_prefix whitelist seeded for Int32/std_msgs identifiers in earlier phases.

Paired apps PR: examples/microros_{srv,cli}: Add minimal lifecycle GetState service example. (apache/nuttx-apps). This nuttx PR must merge first — otherwise the apps PR fails nxstyle CI on the new examples.

Impact

• Users: None. nxstyle whitelist is checkpatch-only; no runtime code
  affected.
• Build: None.
• Hardware: None.
• Docs / Security / Compatibility: None.

Testing

Host: Ubuntu 22.04 jammy on AWS EC2 m7i-flex.large, gcc-12.

$ tools/checkpatch.sh -g 445a59a048
... no nxstyle errors on tools/nxstyle.c diff ...

Built the apps examples (microros_srv, microros_cli) on top of sim:nsh against this whitelist — both compile clean and pass tools/checkpatch.sh after this change. Without this change, tools/nxstyle flags identifier-naming violations on every rosidl-generated lifecycle_msgs__* symbol the new examples reference.

Runtime behavior of the examples themselves is covered in the paired apps PR Testing section (GetState round-trip with ros2 service call against a docker micro-ros-agent:jazzy).

[linguini1]

Some of these are really generic identifiers (State, GetState, etc.). Maybe we should find a more permanent solution than just blanket whitelisting them? Can we restrict them to specific library? Maybe certain directories in apps/ can have nxstyle.txt file with a list of identifiers to whitelist in that directory only?

I just think that the more we add here, the less will be caught later in different apps where these shouldn't be whitelisted. Thoughts?

[arjav1528]

Some of these are really generic identifiers (State, GetState, etc.). Maybe we should find a more permanent solution than just blanket whitelisting them? Can we restrict them to specific library? Maybe certain directories in apps/ can have nxstyle.txt file with a list of identifiers to whitelist in that directory only?

I just think that the more we add here, the less will be caught later in different apps where these shouldn't be whitelisted. Thoughts?

Good point. "State" and "GetState" are way too generic on their own. They're also redundant: the lifecycle_msgs prefix already matches the full mangled identifiers (lifecycle_msgs__srv__GetState_Request, lifecycle_msgs__msg__State, etc.), so dropping the bare ones doesn't lose coverage for this case. I'll amend to keep only lifecycle_msgs and rosidl_runtime_c — both are package-prefixed and unlikely to collide.

EDIT : ammended

[linguini1]

Good point. "State" and "GetState" are way too generic on their own. They're also redundant: the lifecycle_msgs prefix already matches the full mangled identifiers (lifecycle_msgs__srv__GetState_Request, lifecycle_msgs__msg__State, etc.), so dropping the bare ones doesn't lose coverage for this case. I'll amend to keep only lifecycle_msgs and rosidl_runtime_c — both are package-prefixed and unlikely to collide.

EDIT : ammended

Idk if that was an LLM answer but that's not my main concern. My concern is that the ignored symbols should have some way to be restricted to a single directory (like your micro-ros library in nuttx-apps) so that we don't miss style issues in other code. It seems to me like there are a lot of style issues that can't be solved with micro-ros, and I'm sure some of those symbols are going to overlap with other places.

[arjav1528]

Good point. "State" and "GetState" are way too generic on their own. They're also redundant: the lifecycle_msgs prefix already matches the full mangled identifiers (lifecycle_msgs__srv__GetState_Request, lifecycle_msgs__msg__State, etc.), so dropping the bare ones doesn't lose coverage for this case. I'll amend to keep only lifecycle_msgs and rosidl_runtime_c — both are package-prefixed and unlikely to collide.
EDIT : ammended

Idk if that was an LLM answer but that's not my main concern. My concern is that the ignored symbols should have some way to be restricted to a single directory (like your micro-ros library in nuttx-apps) so that we don't miss style issues in other code. It seems to me like there are a lot of style issues that can't be solved with micro-ros, and I'm sure some of those symbols are going to overlap with other places.

makes sense, I kinda agree that global whitelist has this problem already, std_msgs, int32, etc. are all same shape, further will collide with anything else which are using those names. The current PR follows that existing precedent for microROS bits that I need.

what should I do, like should I land this as is, and open a new PR adding nxstyle.txt lookup from the source file
or hold this PR, implement the dir-scoped mechanism first, and then ship lifecycle_msgs only inside the per-dir file

(btw: I agree that the comment you mentioned was almost an LLM ans.. "almost")

[linguini1]

Maybe this discussion should be had with the mailing list since it concerns one of the "inviolables", but my preferred solution would be:

• Modifying nxstyle to support a .nxstyleignore file or something similar, scoped to a single directory
• Add all of these specific symbols to a .nxstyleignore in the micro-ros directory
• Add some updated documentation explaining how .nxstyleignore can only be used for third-party libraries with public-facing code where it is not possible to modify the symbols to conform to nxstyle

As bonus, we should move all the globally ignored symbols to .nxstyleignore files for other locations mentioned in the "ref" comments, but I don't think it's fair to ask that of you.

However, we should see what other people think. Maybe I'm just crazy :)