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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Aug 27 13:51:44 PDT 2018


Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
                 CC|                            |mcatanzaro at igalia.com

--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Comment on attachment 348180
  --> https://bugs.webkit.org/attachment.cgi?id=348180

View in context: https://bugs.webkit.org/attachment.cgi?id=348180&action=review


(Read that in a John Oliver voice.)

BTW I still think this is worth notice on webkit-dev at .

> Source/WTF/wtf/Compiler.h:395
> +#define _COMPILER_CONCAT_I(a, b) a ## b
> +#define _COMPILER_CONCAT(a, b) _COMPILER_CONCAT_I(a, b)
> +
> +#define _COMPILER_STRINGIZE(exp) #exp

I would #undef them when you're done with them

> Source/WTF/wtf/Compiler.h:440
> +#define IGNORE_WARNING_CLANG(warning) do { IGNORE_WARNING_IMPL(clang, warning) } while (false)
> +#define IGNORE_WARNING_CLANG_END(warning) do { IGNORE_WARNING_END_IMPL(clang, warning) } while (false)
> +#define IGNORE_WARNING_CLANG_TOP_LEVEL(warning) IGNORE_WARNING_IMPL(clang, warning)

I kinda think getting rid of the TOP_LEVEL would be nice, to reduce the verbosity and complexity. The inner-function version with the do { } while is only different so that a semicolon can be used at the end, right? Generally the do { } while idiom is intended to make macros easier to use, not harder, and I think it is not really worth it in this case because now you've found up having to duplicate every macro here, and the user has to remember the differences between the two macros (one requires a trailing semicolon, the other doesn't).| It has kinda backfired here, IMO. So I would remove the do { } while versions and require that the semicolon is never used. I think it's not unnatural given that this macro is a replacement for pragmas, not a function, and  hopefully nobody is going to expect it can be used as a function.

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/20180827/0f9300cc/attachment.html>

More information about the webkit-unassigned mailing list