-
Notifications
You must be signed in to change notification settings - Fork 388
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
popo/user_trigger.hpp:33:5: error: exception specification of explicitly defaulted default constructor does not match the calculated one #494
Comments
I did a first investigation and where unable to reproduce the bug on @BH1SCW would it be possible for you to switch for now to the latest Mac OS Version with the latest clang compiler? |
@elfenpiff |
Our company's vpn software has compatibility issues with the latest mac os, that‘s the reason why I still not upgrade my OS. |
…r msvc and mac Signed-off-by: Christian Eltzschig <me@elchris.org>
With the #490 PR this specific error should be fixed. There are about 30 further usages of |
Are all those occurences leading to compile errors? I'm still struggeling to understand what causes the error. If a c'tor has |
From what I understand, some compiler have sometimes problems with it. Maybe it's similar to defaulting a copy/move ctor. If there is a member which has no copy/move ctor, defaulting implicitly means deletion. In this case it might be the same with members without ctors with the |
@mossmaurice At least it was a problem on my side with the 20.04 some time ago. I just changed the compiled stuff only, but for the master it needs to be everywhere corrected (else somebody builds e.g. a test and it fails again).
If you remove the noexpect its gone or if you define the constructor empty. |
Okay, I did a small test. If you have a member of a class with |
I vote for implementing an empty default ctor! |
on the other hand, this would also apply to defaulted copy/move ctors and we were not anymore able to do the rule of zero since a class without a ctor will implicitly be nothrowable except if it has a member which does throw, then it's implicitly throwable ... my head just banged on the table 🤕 |
Are you sure? Do you have a Godbolt snippet for that? According to here and here, they even went back and forth in the committee 😒
I suppose we should check if we can fix the clang build by changing the build to C++17 or adding some magic compiler option which works as written above. |
Just a short recap.
Therefore, we should use |
I don't have a godbolt snippet, but you can run this locally #include <iostream>
#include <type_traits>
struct Bar {
Bar() noexcept(false) = default;
Bar(const Bar&) noexcept(false) = default;
Bar(Bar&&) noexcept(false) = default;
};
struct Foo {
Foo() noexcept = default;
Foo(const Foo&) noexcept = default;
Foo(Foo&&) noexcept = default;
Bar b;
};
int main() {
std::cout << "Is nothrow default constructible: " << std::is_nothrow_default_constructible<Foo>::value << std::endl;
std::cout << "Is nothrow move constructible : " << std::is_nothrow_move_constructible<Foo>::value << std::endl;
} @elfenpiff I also came to the same conclusion, but what if the class is from the STL, e.g. |
@elBoberido you are right but then we would have to write our own atomic since we explicitly do not allow any kind of exception. But I think the atomic does throw nothing so we should be safe in this case. |
@elfenpiff the atomic was just an (maybe bad) example. The problem is that some types of the STL might cause the deletion of a defaulted noexcept ctor. That's out of reach for us to fix. |
@elfenpiff I just found an example for an STL type which causes the deletion on a defaulted noexcept ctor when used as member
|
And with this |
@BH1SCW can you check if the current master works for you? We need to find a proper solution to prevent this breakage in the future, so I would keep this issue open |
I just checked, current master is ok. |
MacOS Mojave (10.14) is available as image from GitHub CI. Question is, do we need to support also the older versions of MacOS? I guess in future it can happen that the container is removed then. I would also vote against an additional build because the worker for MacOS are more limited than Ubuntu: https://docs.github.com/en/github/setting-up-and-managing-billing-and-payments-on-github/about-billing-for-github-actions. One possibility is to install the older clang version on the actual MacOS runner and have an additional build step to compile with it. |
@dkroenke I think we have to check what is needed to become Tier1 in ROS2 and align with that. |
According to the current https://www.ros.org/reps/rep-2000.html for ROS2 Foxy and Galactic is MacOS Mojave (10.14) needed. It can happen that in future MacOS support is downgraded to Tier3: https://github.com/ros-infrastructure/rep/pull/291/files But also there is Mojave mentioned. |
Signed-off-by: Dietrich Krönke <dietrich.kroenke@apex.ai>
Signed-off-by: Dietrich Krönke <dietrich.kroenke@apex.ai>
…ithub-CI Signed-off-by: Dietrich Krönke <dietrich.kroenke@apex.ai>
Signed-off-by: Dietrich Krönke <dietrich.kroenke@apex.ai>
Iox #494 set MacOS Mojave in GitHub CI
Required information
Operating system:
Mac OS Mojave
Compiler version:
Apple clang version 11.0.0 (clang-1100.0.33.12)
Target: x86_64-apple-darwin18.6.0
Observed result or behaviour:
iceoryx/iceoryx_posh/include/iceoryx_posh/popo/user_trigger.hpp:33:5: error: exception specification of explicitly defaulted default constructor does not match the calculated one
UserTrigger() noexcept = default;
^
1 error generated.
gmake[2]: *** [posh/CMakeFiles/iceoryx_posh.dir/build.make:577: posh/CMakeFiles/iceoryx_posh.dir/source/popo/user_trigger.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:384: posh/CMakeFiles/iceoryx_posh.dir/all] Error 2
gmake: *** [Makefile:172: all] Error 2
Expected result or behaviour:
no build error
Conditions where it occurred / Performed steps:
git commit id:
commit f1c4b31
The text was updated successfully, but these errors were encountered: