[cfe-dev] Warning when calling virtual functions from constructor/desctructor?

Aaron Ballman via cfe-dev cfe-dev at lists.llvm.org
Wed Dec 19 06:22:03 PST 2018

On Tue, Dec 18, 2018 at 6:59 PM Artem Dergachev via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Static Analyzer's checker already has a mode in which it warns on case B, but it's off by default because it is surprisingly noisy. In particular, i vaguely recall that i've seen ~90 warnings on the OpenOffice codebase - none of them were pure virtual calls and most of them looked like false positives in the sense that the virtual function is called intentionally. Which means that i would be generally worried about this warning. That said, i don't know how warnings are accepted into Clang and whether there is a threshold on intentional violations. I suspect that it depends on whether the warning is expected to be on by default or be part of -Wall or only -Weverything.

In general, warnings in Clang are expected to be on-by-default and
have an extremely low false positive rate (certainly lower than for
the static analyzer). I suspect this warning would not meet the usual
bar for inclusion as a Clang warning given the number of false
positives it's shown in the past. I think the static analyzer is a
better place for the functionality to live, especially given that it
requires actual static analysis of runtime control flows to reduce
those false positives.

> Another good thing to do with a warning that may be intentionally triggered by the user is to add a hint on how to suppress it. Eg., how -Wparentheses does it:
>   test.c:2:9: note: place parentheses around the assignment to silence this warning
>     if (x = 1) {
>           ^
>         (    )
> I guess you could add a note that suggests to qualify the call with a class name, which is a good thing to do anyway. With that, in my opinion it'd be a good warning.

Agreed that this would be a sensible way for users to suppress the
diagnostic -- it clarifies that the programmer understands the
behavior of the call.


More information about the cfe-dev mailing list