[PATCH] D55388: [analyzer] MoveChecker Pt.8: Add checks for dereferencing a smart pointer after move.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D55388#1322601 <https://reviews.llvm.org/D55388#1322601>, @xazax.hun wrote:

> Hm. I wonder if it would also make sense to model e.g. the get method to return nullptr for moved from smart ptrs. This could help null dereference checker and also aid false path prunning.


Apart from "yeah, totally, and we should also model the whole standard library", i'm also a bit uncomfy to rely on this generic checker for something as specific as `evalCall()`. This whole patch should probably be split out into a separate checker that shares state with the move checker but is dedicated to smart pointers specifically. I'm pushing for this before coming up with generic standard library modeling because i was asked to do this specific check. Not sure how much should i push it though. Null dereferences via `.get()` are definitely a tasty addition.

Another random thought: should we make a mechanism through which checkers could send events to each other? Imagine move checker notifying other checkers that an object is being moved, and checkers subscribed to such custom event could immediately react accordingly. Kinda checker-defined checker callbacks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55388/new/

https://reviews.llvm.org/D55388