[cfe-dev] Feature request: Don't warn for specified "unknown" attribute

[Justin Bassett via cfe-dev]

>
> That's correct, but it's useful beyond just detecting typos. Different
> vendors support different sets of attributes and this diagnostic is
> how a developer can tell whether Clang is ignoring a given attribute
> or not. It can be very difficult to tell the difference between
> "parsed and silently ignoring this attribute" and "parsed attribute
> and it functions as designed" depending on the attribute without this
> diagnostic. For example, in order to tell whether
> __attribute__((deprecated)) is supported, you would have to alter code
> to see that it's behaving by design; otherwise, the declarations are
> just silently marked as deprecated.
>

Indeed, which is why I want the warning turned on by default (not that it's
a default compiler warning, but that it's on for all attributes "by
default" when the warning is turned on).

> To solve this, I propose that we add the ability to specify attributes to
> ignore for -Wunknown-attributes. In other words, something like this:
> '-Wignore-unknown-attribute=some_ns::some_attribute'.
>
> What issue is being solved, though? If the user wishes to ignore a
> specific attribute on Clang because it's not known to the
> implementation, the better solution is to use the preprocessor to
> provide decent fallback behavior for the attribute. This is why
> __has_attribute and friends exist. Is there a different problem that
> this new warning flag behavior solves?
>
> ~Aaron
>

No, this problem is not solved by the preprocessor. Yes, most C++ code
bases today use the preprocessor to hack around this, but IMO, this is a
broken solution. C++17 states that unknown attributes should be ignored,
not warned on (although I believe the compiler is within its rights to
warn). I strongly feel that users should be able to use attributes without
macros, otherwise C++11 attributes lose a lot of their appeal, almost to
the point where vendor-specific attribute syntaxes should have continued as
the way forward.

In short, I would argue that the preprocessor is a worse solution, as
requiring it blocks the perfectly valid syntax of using a C++11 attribute,
and using it requires a lot more work to set up the macro.

Regards,
Justin

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190416/32010c0e/attachment.html>