Detects calls to std::unique_ptr::release where the return value is unused.
Details
Diff Detail
Event Timeline
Maybe. I can move it if all the reviewers think that it would be better suited there.
Yup, bugprone- should be a better category for this, IMO.
I wonder whether libc++ folks are interested in marking unique_ptr::release() with __attribute__ ((warn_unused_result)). A compiler warning (with -Werror) would be a better protection against this kind of a bug.
There's a push in WG21 to mark more of the library with [[nodiscard]]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0600r1.pdf
If we have a check for this, I do not think it should be specific to unique_ptr::release(), but instead be more broadly applicable to APIs that should be marked [[nodiscard]] but are not (currently). P0600R1 is a good place to start, but I'm guessing there are POSIX APIs (among others) that would also qualify.
P0600R1 seems to suggest quite conservative approach (and rightly so, IMO) in taking [[nodiscard]] in use in std lib. For example it proposes *not* to use it with unique_ptr::release. I think there could still be room for static unused ret val checking for parts of std lib not covered by P0600R1, but also for boost, POSIX APIs etc.
What do you think about making this check fully configurable through the check options? The options could list the functions to check. The documentation could suggest some candidate functions from std lib to configure checks for.
What do you think about making this check fully configurable through the check options? The options could list the functions to check. The documentation could suggest some candidate functions from std lib to configure checks for.
That sound reasonable. A similar approach has been used for cppcoreguidelines-no-malloc already.
Agreed; that's largely what I was suggesting with my previous comment. I think this should be a generic, configurable check that is prepopulated with some APIs that make sense. You can use P0600R1 as a starting point, but I'd encourage you to find a pretty decent (but still conservative) list of APIs.
Closing this as more general check is being reviewed here: https://reviews.llvm.org/D41655
Please put in list of new checks in alphabetical order.