<div dir="ltr"><div>What I like about having this kind of diagnostics being part of clang itself is that you can turn them into errors using -Werror=, and prevent bugs to even been written, saving you debugging time.</div><div>I'm not sure how static code analysis is done on the projects you are working on, but from my experience, it is usually done as part of the CI (so after you commit your changes): this saves you from having bugs reaching the release stage, but doesn't save you the time spent debugging a silly error that could have been catch by the compiler.</div><div>On the other hand, I understand that you don't want this kind of diagnostic to significantly slow down the compilation process (I guess that would be the case here, but I'm not sure).</div><div><br></div><div>Arnaud</div></div><br><div class="gmail_quote"><div dir="ltr">Le jeu. 13 déc. 2018 à 16:21, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Dec 13, 2018 at 10:08 AM Arnaud Bienner via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi all :)<br>
><br>
> I noticed that clang doesn't emit a warning in this case.<br>
> It does when calling a *pure* virtual function though (a warning for which I added a diagnostic group recently [1]).<br>
> I think one difference is that calling pure virtual function from constructor is undefined, while calling virtual function is defined (it calls the base class function since the vtable isn't filled yet with inherited virtual functions reimplementations).<br>
> So implementing a warning like this will likely trigger false positives.<br>
><br>
> However, I think in most cases it denotes a bug, since many IMHO C++ developers won't get that the function will not behave as they might expect.<br>
> Also, we can have a fixit to this, by suggesting the user to to specify the class of the function e.g. write "B::f()" instead of "f()".<br>
><br>
> I'm fine (trying to) write a patch for this, but first I wanted to get opinions about whether it's worth it.<br>
> I guess it might not be that much difficult to do for simple cases (when calling virtual function directly). I expect it might be more difficult to catch cases where we call a function that is not virtual, but which calls a virtual function behind the scene.<br>
> Also, if you're worried about having too many false positives, I think we could put this new warning behind Wextra.<br>
><br>
> What do you think?<br>
<br>
The static analyzer currently has alpha.cplusplus.VirtualCall that<br>
should catch this sort of issue. Given the concerns about false<br>
positives, perhaps that check could be improved enough to pull it out<br>
of alpha status instead of working on a check within clang itself?<br>
<br>
~Aaron<br>
<br>
><br>
> Best regards,<br>
> Arnaud<br>
><br>
> [1]: <a href="https://github.com/llvm-mirror/clang/commit/528a1d17a3ff8361fdd4a1a379adf3f64ec68e00" rel="noreferrer" target="_blank">https://github.com/llvm-mirror/clang/commit/528a1d17a3ff8361fdd4a1a379adf3f64ec68e00</a><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>