[llvm] r216170 - Make format_object_base's destructor protected and non-virtual.

Patrik Hägglund H patrik.h.hagglund at ericsson.com
Sat Aug 23 02:58:53 PDT 2014


> In all seriousness, we need to find a solution to this soon, or revert this change.

+1

> For those who want to use old/pre-installed/official release clangs rather than more recent iterations, they can just disable -Werror (it's not the default anyway).

For us, disabling -Werror is currently not an option. If this is the intention, I think the policy should be updated first. (I would rather like the policy to be strengthened, to support -Werror builds with the latest official release of _both_ clang and gcc.)

/Patrik Hägglund

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Owen Anderson
Sent: den 23 augusti 2014 07:50
To: David Blaikie
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm] r216170 - Make format_object_base's destructor protected and non-virtual.


On Aug 22, 2014, at 10:38 AM, Owen Anderson <resistor at mac.com<mailto:resistor at mac.com>> wrote:



On Aug 21, 2014, at 2:14 PM, David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>> wrote:

On Thu, Aug 21, 2014 at 1:34 PM, Justin Bogner <mail at justinbogner.com<mailto:mail at justinbogner.com>> wrote:

Benjamin Kramer <benny.kra at googlemail.com<mailto:benny.kra at googlemail.com>> writes:

Author: d0k
Date: Thu Aug 21 06:22:05 2014
New Revision: 216170

URL: http://llvm.org/viewvc/llvm-project?rev=216170&view=rev
Log:
Make format_object_base's destructor protected and non-virtual.

It's not meant to be used with operator delete and this avoids
emitting virtual dtors for every derived format object.

This change is obviously for the better, but it triggers a warning when
building with clang 3.4 (and probably every clang back to 2.9 or so),
which is pretty unfortunate.

The problem is, until r208449, we didn't know not to warn about this on
final classes or when the destructor was protected. I'm not entirely
sure what we should do here, but this is likely to break anyone who
builds with -Werror for a while.

Only if they don't update their compiler - I usually just roll my
clang release compiler (disabling -Werror) when this sort of thing
comes up.

For those who want to use old/pre-installed/official release clangs
rather than more recent iterations, they can just disable -Werror
(it's not the default anyway).

This isn't a workable solution for some of us who are tied to specific toolchain releases and can't upgrade on a moment's notice.  And even if I'm not building with -Werror, this change generates hundreds or thousands of warnings across an LLVM build, which makes it practically impossible to do any development work because of my own work getting lost in the sea of noise.

In all seriousness, we need to find a solution to this soon, or revert this change.  In addition to breaking our no-warnings-with-clang policy (and no, pre-releases from SVN don't count), it is causing significant blockage for a lot of developers on our end.

-Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140823/48071cc5/attachment.html>


More information about the llvm-commits mailing list