Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve support for rust language analyzers #34

Closed
ruffsl opened this issue Nov 7, 2020 · 4 comments · Fixed by #64
Closed

Improve support for rust language analyzers #34

ruffsl opened this issue Nov 7, 2020 · 4 comments · Fixed by #64

Comments

@ruffsl
Copy link
Contributor

ruffsl commented Nov 7, 2020

During the last Rust WG meeting, members reported difficulties in trying to get rclrs to play nicely with VSCode + Rust-Analyzer. In particular, one of the hangups is that rust-analyzer gets confused by auto generated messages, and can’t recognize them as types. This could tie into some of the other tickets for improving message generation and build integration with cargo, although this ticket specifically tracks issues for improving support for rust language analyzers such as rls or rust-analyzer:

This'll not only aid in rclrs development, but also help downstream users creating their own ROS Rust packages.

Related:

@ruffsl
Copy link
Contributor Author

ruffsl commented Nov 7, 2020

@kjeremy @jhdcs @gbiggs , I recall you had started discussing this topic on the Rust WG proposal post along this thread:
https://discourse.ros.org/t/proposal-rust-working-group-for-ros/16993/30

@kjeremy
Copy link

kjeremy commented Nov 7, 2020

@ruffsl

As mentioned in that thread the issue is that the included examples copy the Cargo.toml and inject entries for the messages during build. If you open the build space folder in vscode then rust-analyzer will give you types. The easiest solution from the rls/rust-analyzer POV would be to include those in the Cargo.toml or maybe build.rs from the beginning.

@jhdcs
Copy link
Collaborator

jhdcs commented Nov 10, 2020

The easiest solution from the rls/rust-analyzer POV would be to include those in the Cargo.toml or maybe build.rs from the beginning.

I think that this may be the best solution. I can forsee people using rclrs not knowing that they have to open the build space folder for rclrs in order to get types for whatever crate they're working on. This would be especially bad if they didn't download ROS 2 from source.

@gbiggs
Copy link

gbiggs commented Nov 20, 2020

This sounds like we should expect users to do with Cargo.toml what they have to do with CMakeLists.txt in a CMake or ament_cmake package: Include the message information in two places. It's as lovely a solution as it is in those other packages, but it seems it would solve the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants