[Webkit-unassigned] [Bug 188996] Add IGNORE_WARNING_.* macros

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=188996

--- Comment #18 from Guillaume Emont <guijemont at igalia.com> ---
(In reply to Michael Catanzaro from comment #16)
> E.g.
> 
> ../../../../Projects/epiphany/src/ephy-action-bar.c:32: warning: ignoring
> #pragma clang diagnostic [-Wunknown-pragmas]
>  #pragma clang diagnostic ignored "-Wformat"
> 
> I think Visual Studio warns too? I seem to remember that being a problem in
> the past. So if we have just a generic IGNORE_WARNING() it will always need
> to be wrapped in #if COMPILER() guards, both at the start and the end:
> 
> #if COMPILER(GCC_OR_CLANG)
> IGNORE_WARNING("-Wformat")
> #endif
> 
> printf(/* ... */);
> 
> #if COMPILER(GCC_OR_CLANG)
> IGNORE_WARNING_END("-Wformat")
> #endif
> 
> and that's only one line shorter than the current idiom:
> 
> #if COMPILER(GCC_OR_CLANG)
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wformat"
> #endif
> 
> printf(/* ... */);
> 
> #if COMPILER(GCC_OR_CLANG)
> #pragma GCC diagnostic pop
> #endif
> 
> Hence having the compiler-specific macros seems useful, since that gets us
> down to:
> 
> IGNORE_GCC_OR_CLANG_WARNING("-Wformat")
> printf(/* ... */);
> END_IGNORE_GCC_OR_CLANG_WARNING("-Wformat")
> 
> which is very nice. We probably don't need the warning argument to the
> _END() macro either, since it's just doing a pop and must be ignored, but it
> seems nicer (more parallel) and more readable to keep it there.
We currently need the warning argument since the "diagnostic push" is guarded by an #if __has_warning() on clang. Alternatively, we could decide to agree to insert unnecessary pragma push/pop pairs to remove the argument, though I feel in some cases we would end up doing:

IGNORE_GCC_OR_CLANG_WARNING("-Wfoo-bar")

// hundreds of line of code

IGNORE_GCC_OR_CLANG_WARNING_END() // -Wfoo-bar

So for these two reasons (explicitness and avoiding unnecesary pragmas) I feel like it might be better to keep the argument for the _END macros.

> 
> Notice that I played a bit with the name of the macros in that last example
> (moving the END to the beginning rather than the end of the macro name).

That's a good idea. My name ordering showed that I'm not a native English speaker ;).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180828/92b3d533/attachment.html>