-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add clang tidy warning for move constructors and assignments without noexcept #23893
Comments
Looks like an easy one for a new contributor. Patches are welcome! ;) |
I'd like to ask that this is prioritized. I would very strongly like to have this. If no where else, LLVM could benefit heavily from this when using custom types in data structures. |
Should we complain about move constructors declared with noexcept(false), or should this be considered a way to silence the warning? |
If it's noexcept(expr) where expr is evaluated to be false then the warning should be issued. If it's noexcept(false) with a literal false then the warning should not be issued. I would hope there is still a way of suppressing clang tidy warnings in general. Ideally only types ever used inside STL containers or other places where noexcept move semantics are crucially important should generate these warnings, but I'd prefer a false positive here than no warning at all. There is also the matter of throw capable code being in a destructor. Under C++ 11 destructors are all default noexcept, and therefore a throw must never reach a destructor edge. A ton of people converting code from C++ 03 fail to adjust their destructors. I'll add another feature request. Niall |
Sent http://reviews.llvm.org/D9933 for review. |
The check is there, but no fix-it hints for now. |
Error in the current implementation of this check. The check warns when move constructor/assignment operator is marked noexcept and is explicitly defaulted. |
1 similar comment
Error in the current implementation of this check. The check warns when move constructor/assignment operator is marked noexcept and is explicitly defaulted. |
Anthony, please file a separate bug with an example and an explanation of why you think this is a wrong behavior. |
Looks like Bug 24712 fixes this behavior. |
Extended Description
Chandler told me to file a feature request adding a clang tidy check giving warnings for when move constructors or assignment operators are not marked noexcept.
I sometimes forget the noexcept. I am sure so do others.
Niall
The text was updated successfully, but these errors were encountered: