ros2_rust with VS Code?

[michalfita]

Does anyone can suggest a way how to properly setup VS Code to work with rust-analyzer and workspace with ros2_rust in it and doing so w/o Docker? Under normal circumstances rust-analyzer plugin doesn't seem to recognise ROS2 workspace as something having multiple crates under src/ despite .cargo directory there.

I've added some crate paths to "rust-analyzer.linkedProjects" in .vscode/settings.json, but then rust-analyzer doesn't see patches set for crates.io and tries to obtain dependencies from there.

This looks like deficiency to me of the rust-analyzer itself it can't source given files in shell used to start the Language Server.

Edit: Forgot to mention earlier, I'm using remote access, so VS Code launched on the host and VS Code Server is spawned over SSH on remote machine.

Has anyone been successful with this endeavour?

[mxgrey]

I use VS Code with rust-analyzer and ros2-rust in a workspace with the repos file imported. I haven't had any problem with code completion.

All I do is:

1. source the install/setup.bash of the workspace
2. open code in the rclrs directory (or the root directory of whichever project I want to work on)

This should work for the following reasons:

• Sourcing install/setup.bash should take care of linking against rcl and other system dependencies.
• colcon build should generate .cargo/config.toml in the root directory of the colcon workspace, which should provide patching information for rust-analyzer as long as you use it from a child directory within the workspace

If this isn't working I would start by checking what's inside the .cargo/config.toml file in your colcon workspace.

I would also check whether cargo build works when you run it from inside the rclrs directory. In my experience, as long as cargo build works in the source directory, rust-analyzer also works.

[mxgrey]

Not sure if this might be helpful, but it popped up as I poked around Google: https://docs.ros.org/en/jazzy/How-To-Guides/Setup-ROS-2-with-VSCode-and-Docker-Container.html

[michalfita]

I think companies will usually have one person make a docker image for a VS Code development environment and then share that image with all their colleagues.

Valid point. However, I'm using our target board connected to hardware we're talking to and I need access to device drivers - setting that up to be accessible connectedly inside the container is a page of compose scripts 🤦🏼 and still doesn't guarantee it would work correctly.

[michalfita]

With a help from Perplexity (am I saying this?) I've added following to the .bashrc:

if [[ -n "$SSH_CONNECTION" && -n "$VSCODE_GIT_ASKPASS_NODE" ]]; then
    echo "Setting up ROS 2 Humble environment for VS Code only."
    source /opt/ros/humble/setup.bash
fi

And that fires up in VS Code's terminal.

But rust-analyzer's output is still:

025-03-27T10:20:03.539037096Z ERROR Flycheck failed to run the following command: CommandHandle { program: "/home/manveru/.cargo/bin/cargo", arguments: ["check", "--workspace", "--message-format=json-diagnostic-rendered-ansi", "--manifest-path", "/home/manveru/projects/ros2_workspace/src/ros2_rust/rclrs/Cargo.toml", "--keep-going", "--all-targets"], current_dir: Some("/home/manveru/projects/ros2_workspace/src/ros2_rust/rclrs") }, error=Cargo watcher failed, the command produced no valid metadata (exit code: ExitStatus(unix_wait_status(25856))):
    Blocking waiting for file lock on package cache
    Updating crates.io index
warning: Patch `rclrs v0.4.1 (/home/manveru/projects/ros2_workspace/install/rclrs/share/rclrs/rust)` was not used in the crate graph.
Perhaps you misspelled the source URL being patched.
Possible URLs for `[patch.<URL>]`:
    /home/manveru/projects/ros2_workspace/src/ros2_rust/rclrs
warning: Patch `example_interfaces v0.9.3 (/home/manveru/projects/ros2_workspace/install/example_interfaces/share/example_interfaces/rust)` was not used in the crate graph.
Patch `rcl_interfaces v1.2.1 (/home/manveru/projects/ros2_workspace/install/rcl_interfaces/share/rcl_interfaces/rust)` was not used in the crate graph.
Patch `rclrs_example_msgs v0.4.1 (/home/manveru/projects/ros2_workspace/install/rclrs_example_msgs/share/rclrs_example_msgs/rust)` was not used in the crate graph.
Patch `rosgraph_msgs v1.2.1 (/home/manveru/projects/ros2_workspace/install/rosgraph_msgs/share/rosgraph_msgs/rust)` was not used in the crate graph.
Patch `std_msgs v4.2.4 (/home/manveru/projects/ros2_workspace/install/std_msgs/share/std_msgs/rust)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
   Compiling rosidl_runtime_rs v0.4.1 (/home/manveru/projects/ros2_workspace/install/rosidl_runtime_rs/share/rosidl_runtime_rs/rust)
   Compiling rclrs v0.4.1 (/home/manveru/projects/ros2_workspace/src/ros2_rust/rclrs)
error: failed to run custom build command for `rosidl_runtime_rs v0.4.1 (/home/manveru/projects/ros2_workspace/install/rosidl_runtime_rs/share/rosidl_runtime_rs/rust)`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_DEV_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.

Caused by:
  process didn't exit successfully: `/home/manveru/projects/ros2_workspace/src/ros2_rust/rclrs/target/debug/build/rosidl_runtime_rs-bd5c6c73e7096712/build-script-build` (exit status: 101)
  --- stderr

  thread 'main' panicked at /home/manveru/projects/ros2_workspace/install/rosidl_runtime_rs/share/rosidl_runtime_rs/rust/build.rs:12:17:
  AMENT_PREFIX_PATH environment variable not set - please source ROS 2 installation first.
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/std/src/panicking.rs:692:5
     1: core::panicking::panic_fmt
               at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/core/src/panicking.rs:75:14
     2: build_script_build::get_env_var_or_abort
     3: build_script_build::main
     4: core::ops::function::FnOnce::call_once
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `rclrs v0.4.1 (/home/manveru/projects/ros2_workspace/src/ros2_rust/rclrs)`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_DEV_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.

[romainreignier]

Hi @mxgrey
When you say:

2. open code in the rclrs directory (or the root directory of whichever project I want to work on)

By project, you mean a Rust binary crate inside a colcon workspace, right?
Given a Rust binary crate named my_rust_node located in colcon_ws/src/my_rust_node, you start VS Code inside the my_rust_node directory, right?

I ask because I do the same but in ROS 1 and C++, I was used to open VSCode in catkin_ws/src/ directory and I could access all my packages in a single VSCode windows (I symlinked the compile_commands.json of each package in their source directory to get the clangd extension working).

In Rust, it would be nice to have that workflow of having a single IDE window but it did not worked for me.

I have not tried the "rust-analyzer.linkedProjects" option mentioned by @michalfita.

[mxgrey]

By project, you mean a Rust binary crate inside a colcon workspace, right?

I start VS Code in the same directory as the Cargo.toml file for whatever I want to work on. For ros2_rust that's the rclrs directory, but in other cases it could be the root directory of a repo with a workspace-type Cargo.toml.

In Rust, it would be nice to have that workflow of having a single IDE window but it did not worked for me.

I suspect that was able to work because catkin for ROS 1 is implemented as one enormous cmake project (... if I recall correctly... it's been almost a decade since I last used catkin...). VS Code can view the entire catkin workspace as one unified project because it all boils down to a single top-level cmake file.

Theoretically the same could be done for Rust by generating a top-level workspace-type Cargo.toml that includes every project in the colcon workspace. I think that would be a reasonable feature request to open for colcon-cargo, although I suspect @cottsay will recommend that this has to be done with a different verb besides build or maybe with an opt-in argument specific to colcon-cargo.