[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #9 from Justin Bassett --- After more reflection, I do believe that ignoring attributes from unknown namespaces is one of the best options. My suggestion of whitelisting attributes falls apart when we consider how many attributes there may be. It's not unreasonable to expect that there could be 100s of unknown attributes, or at least around 30. Having to pass 30-100+ flags to whitelist each of those is not reasonable.
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #8 from Jonathan Wakely --- (In reply to Justin Bassett from comment #7) > and it won't extend to future standardized attributes. That's a Good Thing. If I use a new standardized attribute like [[no_unique_address]] I definitely want to know if the compiler doesn't recognize it, because that affects the ABI of my code.
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 Justin Bassett changed: What|Removed |Added CC||jbassett271 at gmail dot com --- Comment #7 from Justin Bassett --- Currently, the unknown attribute warning means that we get a warning for typos in a whitelisted set of attributes: the standardized attributes and the gnu::attributes. If this set of whitelisted attributes could be extended, that would be the ideal solution, IMO, since the user would also get typo detection for their additional attributes. Something like -Wignore-unknown-attribute=likely -Wignore-unknown-attribute=some_ns::some_attribute . Jonathan Wakely's suggestion is a decent solution to this problem. However, it won't detect typos in user attributes, and it won't extend to future standardized attributes. Another idea is to warn if the edit-distance from the unknown attribute to a known attribute is small. So [[noretrun]] has a small edit distance and could emit a warning with, "Did you mean [[noreturn]]?" And [[some_future_std_attribute]] would emit no warning because it has a large edit distance from all known attributes.
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 Martin Sebor changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #6 from Martin Sebor --- *** Bug 89160 has been marked as a duplicate of this bug. ***
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #5 from Jonathan Wakely --- (In reply to Hannes Hauswedell from comment #3) > BUT if this code generates warnings there is a problem: obviously I don't > want to tell downstream developers that "it's ok, just ignore the warnings" > (since I have a header-only library I cannot pre-decide this). And I cannot > workaround this in code short of introducing a MACRO. Strictly speaking, you can: #ifdef __has_cpp_attribute # if __has_cpp_attribute(likely) [[likely]] # endif #endif statement; It might be ugly, but it doesn't introduce any macro.
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #4 from Martin Sebor --- It's quite unlikely (pun intended) that code randomly sprinkled with various non-standard annotations (attributes, pragmas, or otherwise) will eventually have the same effect across all implementations once they recognize it. With the attribute spec as loose as it is, implementations haven't even converged on the same effect for the standard attributes, so there is little chance that they will for those that aren't specified. I think the expected progression of new attributes is from vendor namespaces to the standard global namespace and so, as Jonathan suggests, not warning by default for unknown attributes in other vendor's namespaces (e.g., [[foo:unlikely]] might be reasonable. Warning for unknown attributes in the global namespace (i.e., [[unlikely]]) or in our own (i.e., [[gnu::unlikely]]) is the right choice. As an aside, while the C++ standard doesn't allow C++ programs to define macros with the same names as those of standard attributes, nothing prevents a non-standard attributes from being #defined as macros (and since C doesn't support attributes of any kind yet, nothing prevents library headers written in C from #defining even C++ standard attributes as macros). This makes relying on non-standard attributes in library headers problematic in either language (and points to a design flaw in the attribute design).
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #3 from Hannes Hauswedell --- (In reply to Jonathan Wakely from comment #2) > It might be reasonable for GCC to silently ignore attributes that use an > unrecognized attribute-namespace. If somebody uses [[clang::foobar]] or > [[acme::rocketboots]] they probably aren't expecting GCC to handle it. > > This could mean silently ignoring typos like [[ngu::unused]] but it's > arguably easier to spot a typo like "ngu" than to spot "warn_unsued_result" > or "alwasy_inlne". That's true, but I would still argue that *by default* GCC should also ignore [[foobar]] if it doesn't know it. Let me elaborate: I develop a header-only library and want to start including [[likely]] so that for newer compilers things "start working" as soon as they pick up the feature. I am ok with [[likely]] not being interpreted by the compiler, that's why a choose an attribute to begin with and not some low-level magic, but if it works, all the better. This is precisely what attributes are designed for and why they are supposed to be ignored if unknown. BUT if this code generates warnings there is a problem: obviously I don't want to tell downstream developers that "it's ok, just ignore the warnings" (since I have a header-only library I cannot pre-decide this). And I cannot workaround this in code short of introducing a MACRO. Note that not being able to workaround the warning makes this different from almost all other warnings I am aware of. And wrapping future attributes in MACROs just to be able to ship code that is warning/error-free clearly defeats the intent of the standard, or not? I am not sure, maybe we should take the question to a reflector?
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #2 from Jonathan Wakely --- It might be reasonable for GCC to silently ignore attributes that use an unrecognized attribute-namespace. If somebody uses [[clang::foobar]] or [[acme::rocketboots]] they probably aren't expecting GCC to handle it. This could mean silently ignoring typos like [[ngu::unused]] but it's arguably easier to spot a typo like "ngu" than to spot "warn_unsued_result" or "alwasy_inlne".
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-02
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
There is value in diagnosing the use of attributes that GCC doesn't know about.
According to the manual -Wattributes also sounds like the right option to
control warnings about unknown attributes. Unfortunately, the option is also
used by GCC to control warnings about known attributes using in a way GCC
either doesn't consider valid or cannot honor and where -Wignored-attributes
might be more appropriate. For example:
warning: ‘packed’ attribute ignored for field of type ‘char’ [-Wattributes]
struct S { __attribute__ ((packed)) char c; };
Here, packed is used correctly but is "ignored" because it is implied on
members whose alignment is 8. (It's ignored internally within GCC but that's
an implementation detail that's opaque to the user. In this instance, I'd say
the warning should not be issued.)
Similarly for:
__attribute__ ((always_inline)) inline void f (void);
__attribute ((noinline)) void f (void);
warning: ignoring attribute ‘noinline’ because it conflicts with attribute
‘always_inline’ [-Wattributes]
__attribute ((noinline)) void f (void);
where there's nothing wrong with either attribute but GCC can only honor one
and has to ignore the other. Here, the warning is useful but distinct in
nature from an unknown attribute (like the one on bug 86243).
IMO, it should be possible to control warnings about attributes unknown to GCC
independently of other warnings about uses of known attributes. Thus
confirmed.
