<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 12, 2015 at 3:02 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Oct 12, 2015 at 2:18 PM, Reid Kleckner via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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. :)</div></div></blockquote><div><br></div></span><div>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).</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>That sounds like a really good idea to me – teach sema that "(x);" has the same meaning as "(void)x;".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Sat, Oct 10, 2015 at 2:50 PM, Nico Weber via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br></div><div>clang has a useful warning -Wunused-value that warns on things such as `4;` (this probably meant to say `return 4;`).</div><div><br></div><div>winnt.h has a macro UNREFERENCED_PARAMETER(x) that's used to mark unused function parameters. It's somewhat commonly used on Windows, for example the default project generated by MSVC uses it a few times. The macro is defined as `#define UNREFERENCED_PARAMETER(x) (x)`, which means if you use it like it's intended:</div><div><br></div><div> void f(int x) {</div><div> UNREFERENCED_PARAMETER(x);</div><div> }</div><div><br></div><div>then clang will emit a -Wunused-value warning for it. How do we want to fix this? Ideas:</div><div><br></div><div>1. Don't. Tell people to not use UNREFERENCED_PARAMETER().</div><div>2. Have a winnt.h wrapper in lib/Headers that undefines this macro, include_next's regular winnt.h, undefines it again, and then defines it to something that doesn't trigger -Wunused-value (say, `(void)p`, or `do { (void) P; } while (0)` or similar).</div><div>3. Change clang's Wunused-value to check if the unused value is expanded from a macro that was defined in a system header that's spelled UNREFERENCED_PARAMETER.</div><div><br></div><div>2 sounds like it has the highest chance of unintended side effects. 3 is a bit hacky, but seems nicest from a user's perspective and isn't worse than other things we do really.</div><div><br></div><div>Other ideas? Opinions?</div><div><br></div><div>Thanks,</div><div>Nico</div></div>
<br></div></div><span>_______________________________________________<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>
<br></span></blockquote></div><br></div>
<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>
<br></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>