[cfe-commits] r158411 - in /cfe/trunk: lib/Sema/SemaDeclAttr.cpp lib/Sema/SemaDeclCXX.cpp test/SemaCXX/warn-unused-member.cpp

[Daniel Jasper]

This already works like I would have implemented it (very conservatively so
this warning is only generated if there is an explicit use of a member). I
added a corresponding test in r159130.

On Thu, Jun 21, 2012 at 8:34 AM, Chandler Carruth <chandlerc at google.com>wrote:

> On Wed, Jun 20, 2012 at 11:33 PM, David Blaikie <dblaikie at gmail.com>wrote:
>
>> On Wed, Jun 20, 2012 at 11:26 PM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>> > On Wed, Jun 20, 2012 at 11:12 PM, Daniel Jasper <djasper at google.com>
>> wrote:
>> >>
>> >> I have looked into both suggestions, but I am not sure what the right
>> >> thing is:
>> >>
>> >> __attribute__((used)): According to the gcc docs, "this attribute,
>> >> attached to a function, means that code must be emitted for the
>> function
>> >> even if it appears that the function is not referenced". It doesn't
>> really
>> >> say anything about silencing warnings and the code emitting part does
>> not
>> >> really apply to fields. I am happy to make this attribute silence the
>> >> warning, but I don't know whether that makes sense.
>> >>
>> >> -Wused-but-marked-unused: We run into trouble if certain field usages
>> are
>> >> only conditionally included (#ifdefs, ...).  In that case, it would be
>> >> impossible to create source code that produces neither
>> >> -Wused-but-marked-unused nor -Wunused-private-field if compiled in
>> different
>> >> modes.
>> >>
>> >> Any thoughts?
>> >
>> >
>> > I really should have thought of this when we chatted. It's quite
>> verbose,
>> > but it works:
>> >
>> > struct S {
>> >   int platform_specific_member
>> > #ifdef __x86_64__
>> >     __attribute__((unused))
>> > #endif
>> >     ;
>> > };
>> >
>> >
>> > We just have to make the attribute itself be conditioned on the same
>> thing
>> > as the use of the member. As long as this attribute never impacts
>> semantics,
>> > this should be fine. Do others thing this is too cumbersome?
>>
>> If you're going to conditionally define its usage, why not just
>> conditionally define the whole variable? (admittedly there are some
>> cases where that might not work, but I'm not sure they're the cases
>> we're dealing with)
>
>
> Certainly, that's another option.
>
> But in many cases, ABI or other concerns prevent that. I should have used
> a better example: NDEBUG.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120625/136b861a/attachment.html>