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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 28 04:31:54 PDT 2018


--- Comment #5 from Guillaume Emont <guijemont 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

>> Source/WTF/wtf/Compiler.h:395
>> +#define _COMPILER_STRINGIZE(exp) #exp
> I would #undef them when you're done with them

I wish I could. But since they are used inside of macros, it looks like they need to be defined wherever the macro is used. I tried to alleviate this by using the _COMPILER_ prefix. I'm open to alternative ideas, but unfortunately, simply #undef'ing them is not an option.

>> Source/WTF/wtf/Compiler.h:440
> 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.

I hear your argument, and I think it makes sense. Though I think that indeed this kind of question is worth asking on webkit-dev at .
To add to your proposition, if we were doing that, what about calling the macors "PRAGMA_IGNORE_WARNING.*" to make it clear that they are "like pragmas" and that's why we don't put semicolons afterwards?

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/86862b33/attachment.html>

More information about the webkit-unassigned mailing list