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

[Arthur O'Dwyer via cfe-dev]

On Tue, Jan 8, 2019 at 1:05 PM John McCall via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On 8 Jan 2019, at 8:37, Arnaud Bienner wrote:
> >
> > I realized I didn't put "DefaultIgnore" on this warning.
> > I'm not experienced enough with clang to know what's the best way to deal
> > with new warnings, but my feeling is that it would be sensible to have
> this
> > new warning DefaultIgnore for now, in -Wall, and make it default once we
> > have some feedback from the community: while not all C++ projects use
> -Wall
> > (or -Wextra) I believe enough do to give us a chance to get some
> feedback.
> >
> > What do you think?
>
> We generally don't add things to -Wall.  That's why I went into my whole
> spiel
> about versioning: I think it's a conversation we need to have before we're
> ready to accept this as a warning that's anything but hidden permanently
> behind its own opt-in flag.
>

John: Wha? Clang *frequently* adds things to -Wall!  -Wall includes -Wmost
which includes a bunch of other categories, so while we don't often put new
diagnostics *directly* under -Wall, pretty much every "reasonable"
diagnostic eventually winds up in there somehow — which is the intent.

However, Arnaud: I don't think there's much difference between
"on-by-default" and "on only with -Wall", because the received wisdom has
always been to always compile with -W -Wall [-Wextra].  You're saying
"don't worry, my change will affect *only* the people who pass -Wall" — but
that's actually a huge percentage of the world, like maybe 90% (wild
unscientific guess).  If you're worried that your diagnostic might be
"unreasonable," then it doesn't belong in -Wall any more than it belongs
on-by-default.

I think Richard Smith's suggestion was right: the decision of where to put
this diagnostic will become simpler if the diagnostic itself becomes more
targeted and loses some of its current false positives.

my $.02,
Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190108/6aec0a72/attachment.html>