[cfe-dev] rfc: winnt.h's UNREFERENCED_PARAMETER() vs clang's -Wunused-value

[Aaron Ballman via cfe-dev]

On Mon, Oct 12, 2015 at 7:41 PM, Richard Smith via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> On Mon, Oct 12, 2015 at 4:21 PM, Nico Weber <thakis at chromium.org> wrote:
>>
>> On Mon, Oct 12, 2015 at 4:11 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>>>
>>> On Mon, Oct 12, 2015 at 3:04 PM, Nico Weber via cfe-dev
>>> <cfe-dev at lists.llvm.org> wrote:
>>>>
>>>> On Mon, Oct 12, 2015 at 3:02 PM, David Majnemer
>>>> <david.majnemer at gmail.com> wrote:
>>>>>
>>>>> On Mon, Oct 12, 2015 at 2:18 PM, Reid Kleckner via cfe-dev
>>>>> <cfe-dev at lists.llvm.org> wrote:
>>>>>>
>>>>>> I'd really rather not do 2. Fighting with MSVC CRT headers over
>>>>>> va_start has been pretty awkward. Users have reported issues with our header
>>>>>> override fails. I'd rather not start fighting with winnt.h.
>>>>>>
>>>>>> I'm OK with 3, but I'm desensitized to having to do this kind of
>>>>>> pattern matching for __uuidof, etc. Maybe we should wait for another +1. :)
>>>>>
>>>>>
>>>>> A +1 from me for option #3 as well.  I'd feel more comfortable doing #2
>>>>> if it was for correctness (along the lines of our  va_start/va_arg hack).
>>>>>
>>>>> On what basis does MSVC decide that UNREFERENCED_PARAMETER should
>>>>> silence an unused parameter?  IIRC, it expands to wrapping it's argument in
>>>>> parenthesis.  Could we teach clang to do the same?  Sounds like it could be
>>>>> a more general fix.
>>>>
>>>>
>>>> That sounds like a really good idea to me – teach sema that "(x);" has
>>>> the same meaning as "(void)x;".
>>>
>>>
>>> Hold on a moment.
>>>
>>> `(x);` certainly seems like it should silence an "unreferenced parameter"
>>> warning (which is what this macro is for in MSVC), but it seems much less
>>> reasonable for it to suppress an "unused value" warning (which is the
>>> warning we're getting with Clang).
>>
>>
>> The reason it seems kind of reasonable to me is that adding parentheses
>> means "I really meant this" in a bunch of places. `if (a = b)` warns but `if
>> ((a = b))` doesn't, for example. So `(x);` seems more natural than
>> `(void)x;` to me. The latter admittedly does have going for it that it's an
>> established convention.
>>
>> Can you think of an example where not warning on `(x);` would catch a bug?
>> Hm, I suppose many people like to always write parens after return, and part
>> of the motivation of -Wunused-value is catching forgetting "return"s. So
>> that's an argument for warning on `(x);`.
>
>
> Perhaps I meant to write `f(x);` and wrote `(x);` instead, or my `x` is a
> callable and I meant to write `x();`. Using parens to mean "I am discarding
> this value" is novel, counter-intuitive, and just not a good pattern,
> whereas the very purpose of permitting casts to void is to allow explicitly
> discarding a value.

Richard has a really compelling point; I think I am more in favor of
preventing the diagnostic only within an UNREFERENCED_PARAMETER macro
expansion. If we really find it's useful to use in a more broad
context, then we can allow it in the future without

~Aaron

>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>