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

[Martin Böhme via cfe-commits]

>
> 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.
      - 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.


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?


See user-facing documentation for details.
>>
>
> In general, I suspect at least some more context should be provided in
> change descriptions. =]
>

Thanks -- still new to this.

The intent was not to repeat myself, but I evidently went a bit far with
that. ;) Is it of value if I provide a short summary on this thread, or is
this just something I should keep in mind for future patches?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160914/bf7af44c/attachment.html>