[clang-tools-extra] r281453 - [clang-tidy] Add check 'misc-use-after-move'

[Chandler Carruth via cfe-commits]

(Somehow I missed this, sorry for silence...)

On Wed, Sep 14, 2016 at 6:13 AM Martin Böhme <mboehme at google.com> wrote:

> While I'm excited to see this go in anywhere, I have to say I'm a bit sad
> it isn't going in as a warning and instead inside clang-tidy. This has been
> a much requested warning from Clang for many years.
>
> Is there a concise description of why this design was chosen? Are there
> specific problems that make it infeasible to be a warnings? Is there maybe
> a plan to move it to a warning after some set of issues are addressed?
>
>
> Yes, my hope is that this can be moved to a warning, and others have
> expressed the same thought to me.
>
> There are two main issues that need to be addressed before this can be
> made a warning:
>
>    - I suspect (though I haven't measured) that the implementation isn't
>    currently efficient enough to be made a Clang warning.
>    - There are a number of scenarios in which the check warns when
>    arguably it should not. These are:
>       - User-defined types that make guarantees about the state of a
>       moved-from object (in the way that std::unique_ptr and std::shared_ptr do).
>       Some form of annotation could be used to indicate that this is the case.
>       - User-defined types that provide a member function to reinitialize
>       the entire object (the way that clear() does on the standard container
>       classes). These could either again be annotated in some way, or we could
>       simply assume that any non-const member function reinitializes the object.
>
> I think it would be good to have a general design discussion about what
the semantic model should be here. I have a somewhat specific and precise
idea of what C++ is going for here based on several previous (extensive)
conversations about this with Richard Smith, David Blaikie, and DeLesley
Hutchins. Notably, DeLesley worked on this and closely related warnings in
Clang for quite some time.


>    - Tests for move constructors / move assignment operators. Often,
>       these tests check that a moved-from object is left in a certain state, even
>       if the class in question does not provide such a guarantee to clients (the
>       intent being to check that the move constructor / move assignment operator
>       do not simply perform a copy).
>
> All of these scenarios are probably somewhat controversial, but I don't
> think there's a broad consensus that any of them should be prohibited, so
> there needs to be a way to silence the warning in these cases.
>
>
The first two are actually pretty critical features of some types, so yea,
this will end up needing to be directly supported.


>
> I do hope to resolve these issues and make this check into a warning, but
> in the meantime, having it available as a clang-tidy check seems like a
> good way to gather feedback and gain experience with it.
>
> Since you say this is a much-requested warning: Any pointers to previous
> discussions that I should be aware of?
>

Searching the interwebs finds at least:
http://lists.llvm.org/pipermail/cfe-dev/2014-October/039468.html

I know internally our users have asked for this repeatedly, I'll send you
info there.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161005/82d95180/attachment.html>