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

Various fixes to build MoveIt with clang #1196

Merged
merged 8 commits into from
Nov 19, 2018
Merged

Conversation

rhaschke
Copy link
Contributor

Fixes #1195.

Copy link

@S-Fichtl S-Fichtl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth, this looks like an appropriate fix to me. Thank you @rhaschke.
There is an identical error in planning_scene.h with the CollisionDetector struct:

/opt/ros/kinetic/include/moveit/planning_scene/planning_scene.h:967:3: error: 'CollisionDetector' defined as a struct here but previously declared as a class [-Werror,-Wmismatched-tags]
struct CollisionDetector
^
/opt/ros/kinetic/include/moveit/planning_scene/planning_scene.h:964:3: note: did you mean struct here?
class CollisionDetector; typedef std::shared_ptr CollisionDetectorPtr; typedef std::shared_ptr CollisionDetectorConstPtr;;;
^~~~~
struct
2 errors generated.

@rhaschke
Copy link
Contributor Author

Thanks for pointing this out. I also added a Travis test to compile with clang. However, this test (using clang 5.0) doesn't complain. There aren't even warnings.
So, could you please provide more details about your environment? Which version of clang do you use?

@S-Fichtl
Copy link

I am using clang 6.0.0 on Ubuntu 16.04 and ROS Kinetic Kame in the standard PPA binary release and the moveit version that comes with it.

$ clang --version
clang version 6.0.0-1ubuntu2~16.04.1 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

@S-Fichtl
Copy link

Speaking of the PPA binary release, is this fix even likely to make it into there?
Either into Kinetic Kame or Melodic Morenia PPA binary release?
Would you have an time estimate for when that might happen?

@rhaschke
Copy link
Contributor Author

We just recently did a release into Kinetic. So there will not be a new release very soon.
For Melodic, we have a release pending. So this fix might be seen in the next two weeks...

@rhaschke rhaschke force-pushed the fix-#1195 branch 4 times, most recently from 25fe37a to 44cb603 Compare November 13, 2018 21:16
@rhaschke
Copy link
Contributor Author

Hm, clang can successfully compile the melodic branch on Melodic/Bionic but not on Kinetic/Xenial.
gcc doesn't have issues.
@S-Fichtl The errors you originally reported, are only warnings for me. Can you confirm?

@rhaschke rhaschke changed the title Consistent type declaration of collision_detection::Object as class Various fixes to build MoveIt with clang Nov 13, 2018
@S-Fichtl
Copy link

That is possible, I didn't check that, sorry. I have the -Werror flag set, so to me it looks like a error. There may be many clang issues hidden away from me on kinetic/xenial, because I only get affected by issues in headers I include.
Hence, at least the headers of libraries should be as warning free as possible to not affect users negatively.
Anyway, I would try to fix warnings instead of switching them off, wherever possible. And where impossible I would add an exception in code around the piece of code that triggers the warning/error, not in the CMakeLists.txt for the whole project. That way a developer has to consciously decide to ignore a warning each time he does.

@rhaschke
Copy link
Contributor Author

rhaschke commented Nov 14, 2018

Fully agree. Just wanted to confirm that this is an error only. There are dozens of these struct vs. class declaration errors and I don't have cycles to work more on this issue now.
So could you check, whether this minimal set of changes already fixes all your issues?

@S-Fichtl
Copy link

I have built moveit from source using your PR branch, but still get the error.
I don't know what I am doing wrong, but I do believe it is on my side as your fix looks like it should fix it.
So I vote for merging since it passes all tests and in the very least doesn't break anything but in my opinion is an improvement.

Copy link
Contributor

@v4hn v4hn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to clang. I'll use this occasion to change my local build to clang too.
Checking the backward compatibility support with clang seems a bit random though.
I would propose to use melodic-melodic-shadow-fixed (latest and greatest) instead.

The clang test fails at the moment though because it can't find the compiler.
You recently added that to the melodic-devel branch directly.
I guess rebasing should resolve this?

add_compile_options(-Wno-maybe-uninitialized)
elseif(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
add_compile_options(-Wno-inconsistent-missing-override -Wno-potentially-evaluated-expression)
endif()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to have comments in here on why these -Wno-* flags were added.
Are these warnings something we should improve in our code base?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These flags improve our code style by throwing warnings for common issues. See my PR #971

I'd like to add this to all the packages in moveit

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No they don't -Wno-* actually disables specific warnings. Probably because @rhaschke either decided they are not important for us, or because some package we rely on throws lots of warnings we can't fix ourselves.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right. I think I might have done this because otherwise some of moveit's dependencies (TF I believe) cause warnings that are hard to fix because they are from some of TF's dependencies outside of ROS.

moveit_core/robot_model/src/robot_model.cpp Show resolved Hide resolved
@rhaschke rhaschke force-pushed the fix-#1195 branch 2 times, most recently from e3120af to 553c799 Compare November 16, 2018 22:32
@@ -16,9 +16,13 @@ env:
- TEST_BLACKLIST=moveit,moveit_ros,moveit_runtime,moveit_ros_perception # mesh_filter_test fails due to broken Mesa OpenGL
matrix:
- ROS_DISTRO=kinetic ROS_REPO=ros TEST=clang-format
- ROS_DISTRO=melodic ROS_REPO=ros UPSTREAM_WORKSPACE=moveit.rosinstall
- ROS_DISTRO=melodic ROS_REPO=ros-shadow-fixed UPSTREAM_WORKSPACE=moveit.rosinstall
- ROS_DISTRO=kinetic ROS_REPO=ros-shadow-fixed UPSTREAM_WORKSPACE=moveit.rosinstall
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we unify these two matrix: sections into one? if not, please add comment explaining why they are different.

seems like we could move all the tests to the below section with compiler: gcc

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you please still address this question? im curious if this can be improved

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This cannot be merged. As we want to use a different compiler (clang), we need to use the include/matrix section, which allows to add individual entries to the matrix.

add_compile_options(-Wno-maybe-uninitialized)
elseif(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
add_compile_options(-Wno-inconsistent-missing-override -Wno-potentially-evaluated-expression)
endif()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These flags improve our code style by throwing warnings for common issues. See my PR #971

I'd like to add this to all the packages in moveit

moveit_core/robot_model/src/robot_model.cpp Show resolved Hide resolved
@rhaschke rhaschke force-pushed the fix-#1195 branch 2 times, most recently from 4aa1c17 to 207f992 Compare November 17, 2018 06:54
- use MOVEIT_STRUCT_FORWARD for structs
- fix initialization of dynamic-size array
- fix implicit conversion for SortableDisabledCollision -> srdf::Model::DisabledCollision
- virtual destructors for classes with virtual methods
- use delete[] for memory allocated with new[]
simple assignment does the job
@rhaschke rhaschke force-pushed the fix-#1195 branch 2 times, most recently from 4c8d442 to 5532fbd Compare November 17, 2018 08:40
This function is only available in KDL >= 1.4.0 (i.e. in Melodic).
For backwards-compatibility with Kinetic, provide compile-time switch.
- use existing moveit::planning_interface::getSharedTF();
- switch based on rviz version (instead of roscpp version)
@rhaschke
Copy link
Contributor Author

Ready for merging.

Copy link
Contributor

@v4hn v4hn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good.

Merging.

#ifdef ROS_KINETIC
std::shared_ptr<tf2_ros::Buffer> tf_buffer = PlanningSceneDisplay::getTF2BufferPtr();
#ifdef RVIZ_TF1
std::shared_ptr<tf2_ros::Buffer> tf_buffer = moveit::planning_interface::getSharedTF();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice simplification!

@v4hn v4hn merged commit f805328 into moveit:melodic-devel Nov 19, 2018
@rhaschke rhaschke deleted the fix-#1195 branch November 19, 2018 15:25
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 this pull request may close these issues.

None yet

4 participants