fix: make sas::Clock a real member so it shadows rclcpp::Clock

[mmmarinho]

What this does

Fixes the Clock name ambiguity that breaks downstream ROS packages when the sas_core thin wrapper is combined with a using namespace rclcpp; — the second failure in the PPA deb builder after the include-path fix in #13.

Problem

The wrapper's shims re-export the core with a using-directive:

// include/sas_core/sas_clock.hpp
namespace sas { using namespace marinholab::sas::core; }

A using-directive makes core names findable in namespace sas but does not declare them there. When a downstream package also has using namespace rclcpp; (e.g. sas_robot_driver) and writes a bare Clock inside namespace sas, name lookup finds both marinholab::sas::core::Clock (via the directive) and rclcpp::Clock (via the global directive) → ambiguous:

sas_robot_driver_ros.hpp:91:5: error: reference to 'Clock' is ambiguous
   91 |     Clock clock_;
candidates are: 'class rclcpp::Clock' and 'class marinholab::sas::core::Clock'

Breaks the PPA deb builder: https://github.com/SmartArmStack/smart_arm_stack_ROS2/actions/runs/35760730121 (job deb builder multiversion multiarch (ubuntu-24.04-arm, jazzy)). The error is arch-independent, so amd64 fails the same way.

Fix

Make Clock a real member of namespace sas in the shim:

namespace sas
{
    using namespace marinholab::sas::core;
    using Clock = marinholab::sas::core::Clock;   // real member → shadows rclcpp::Clock
}

A using-declaration (alias) declares the name in namespace sas, which correctly shadows rclcpp::Clock — exactly matching the pre-refactor monolithic package, where namespace sas had its own class Clock.

Scope notes:

• Only Clock collides with rclcpp; the other core types (Object, RobotDriver, ShutdownSignaler, ThreadManager) and the core free functions keep working through the unchanged using-directive.
• Only sas_robot_driver is affected in the stack (the only package that does using namespace rclcpp; and declares a bare Clock in namespace sas).

Verification

• Verified locally with the real MarinhoLab/sas_cpp headers: a downstream-style consumer (using namespace rclcpp; + bare Clock in namespace sas + clock_.init()) fails with the pre-fix shim (reference to 'Clock' is ambiguous) and compiles with the fix (Clock → marinholab::sas::core::Clock, Node → rclcpp::Node).
• Added a [4/4] regression step to docker/smoke_test.sh covering exactly this consumer. It uses a minimal rclcpp stub (class Clock; class Node): the bug is purely a name-lookup issue, and a stub is name-lookup-identical to the real rclcpp types, keeping the test hermetic and independent of the ROS include layout. CI now logs Ambiguity regression test compiled (no ambiguous Clock) → ALL CHECKS PASSED.

⚠️ Follow-up needed (CI gating — separate change)

While verifying this, I found that the build workflow's run step uses docker compose up, which does not propagate the container's exit code (verified: a container exiting 3 → compose up returns 0). So a failing smoke test cannot fail CI today. The fix is to use docker compose run --rm sas_core in .github/workflows/build.yml. I could not include that here (my token lacks the workflow scope needed to push workflow files). Recommend a small follow-up PR to flip that line so the smoke test actually gates merges.

Next step

After merge, re-run the sas deb builder workflow in smart_arm_stack_ROS2 (it clones sas_core at -b jazzy); the arm and amd64 jobs should now get past sas_robot_driver.

---

This pull request was created by an AI agent (OpenHands) on behalf of the repository owner.

[mmmarinho]

👍