aaronpuchert added inline comments.
================
Comment at: clang/test/Analysis/scopes-cfg-output.cpp:1480
+public:
+ ~F() {}
+};
----------------
tbaeder wrote:
> aaronpuchert wrote:
> > As with the cleanup function, a definition shouldn't be necessary.
> Is there a way to test whether the contents of the cleanup function are being
> checked as well? From these tests, I only know we consider them called, but
> not whether we (properly) analyze their bodies in the context as well. Or is
> that separate from this patch?
For now we're just adding a new element to the CFG and adapting the respective
tests. The CFG is generated on a per-function basis, and the generation of one
function's CFG will never look into another function's body. It might use some
(declaration) properties of course, like whether it has `[[noreturn]]` or
`noexcept`. Of course we should also generate a CFG for the cleanup function,
but that's independent of this change.
Users of the CFG will naturally need to be taught about this new element type
to “understand” it. Otherwise they should simply skip it. Since the CFG
previously did not contain such elements, there should be no change for them.
So we can also initially just add the element and not tell anybody about it.
We could also add understanding of the new element type to other CFG users, but
you don't have to do this. If you only care about Thread Safety Analysis, then
it's totally fine to handle it only there.
But let's move all changes to Thread Safety Analysis into a follow-up, so that
we don't have to bother the CFG maintainers with that.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157385/new/
https://reviews.llvm.org/D157385
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
