Looks like an easy one for a new contributor. Patches are welcome! ;)

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?

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.

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.