<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, 7 Jan 2019 at 16:12, Erik Pilkington via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>On 1/7/19 3:51 PM, Richard Smith wrote:<br></p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Mon, 7 Jan 2019 at 13:57, Erik Pilkington via
cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Author: epilk<br>
Date: Mon Jan 7 13:54:00 2019<br>
New Revision: 350572<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=350572&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=350572&view=rev</a><br>
Log:<br>
Add a __has_feature check for namespaces on #pragma clang
attribute.<br>
</blockquote>
<div><br>
</div>
<div>Should this be __has_extension rather than __has_feature,
since it's not a standard feature?</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>I suppose, but it doesn't really seem like that's the rule that
we're following here. If you look at every other FEATURE(...)
above this, they all have to do with clang extensions like
attributes and sanitizers, which obviously aren't standard
features. Every EXTENSION(...) has to do with language features
that are shared between languages (cxx_fixed_enum in C, for
instance). So it seems like the most internally consistent place
to put this is in FEATURE(...). WDYT?</p></div></blockquote><div>What you're seeing is a historical legacy of the time before the current approach. The design and documented intent of __has_feature is that it checks for standardized features. See the documentation here, and particularly the note about backwards compatibility:</div><div><br></div><div><a href="https://clang.llvm.org/docs/LanguageExtensions.html#has-feature-and-has-extension">https://clang.llvm.org/docs/LanguageExtensions.html#has-feature-and-has-extension</a><br></div><div><br></div><div>... and the design discussion when __has_extension was introduced:</div><div><div><br class="gmail-Apple-interchange-newline"><a href="http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20110425/041452.html">http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20110425/041452.html</a><br></div><br class="gmail-Apple-interchange-newline"></div><div>... and the comment on HasFeature in Lex/PPMacroExpansion.cpp:<br></div><div><br></div><div><div>/// HasFeature - Return true if we recognize and implement the feature</div><div>/// specified by the identifier as a standard language feature.</div></div><div><br></div><div>We seem to have detached that comment from the actual list of features when the features were moved to a .def file. Oops :(</div><div><br></div><div>If we want to revisit the design based on experience using __has_feature / __has_extension, I'm all for that (the distinction between the two seems confusing and not especially useful to me; the behavior of the current language mode can be tested using eg __STDC_VERSION__ and __cplusplus, so the only thing that's really interesting for us to expose is what features the current compliation supports), but we should follow the current design until we do.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Support for this was added in r349845.<br>
<br>
Modified:<br>
cfe/trunk/docs/LanguageExtensions.rst<br>
cfe/trunk/include/clang/Basic/Features.def<br>
cfe/trunk/test/Sema/pragma-attribute-namespace.c<br>
<br>
Modified: cfe/trunk/docs/LanguageExtensions.rst<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=350572&r1=350571&r2=350572&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LanguageExtensions.rst?rev=350572&r1=350571&r2=350572&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/docs/LanguageExtensions.rst (original)<br>
+++ cfe/trunk/docs/LanguageExtensions.rst Mon Jan 7
13:54:00 2019<br>
@@ -2725,7 +2725,9 @@ same namespace. For instance:<br>
Without the namespaces on the macros, ``other_function``
will be annotated with<br>
``[[noreturn]]`` instead of
``__attribute__((unavailable))``. This may seem like<br>
a contrived example, but its very possible for this kind of
situation to appear<br>
-in real code if the pragmas are spread out across a large
file.<br>
+in real code if the pragmas are spread out across a large
file. You can test if<br>
+your version of clang supports namespaces on ``#pragma
clang attribute`` with<br>
+``__has_feature(pragma_clang_attribute_namespaces)``.<br>
<br>
Subject Match Rules<br>
-------------------<br>
<br>
Modified: cfe/trunk/include/clang/Basic/Features.def<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=350572&r1=350571&r2=350572&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=350572&r1=350571&r2=350572&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/include/clang/Basic/Features.def (original)<br>
+++ cfe/trunk/include/clang/Basic/Features.def Mon Jan 7
13:54:00 2019<br>
@@ -69,6 +69,7 @@ FEATURE(attribute_overloadable, true)<br>
FEATURE(attribute_unavailable_with_message, true)<br>
FEATURE(attribute_unused_on_fields, true)<br>
FEATURE(attribute_diagnose_if_objc, true)<br>
+FEATURE(pragma_clang_attribute_namespaces, true)<br>
FEATURE(blocks, LangOpts.Blocks)<br>
FEATURE(c_thread_safety_attributes, true)<br>
FEATURE(cxx_exceptions, LangOpts.CXXExceptions)<br>
<br>
Modified: cfe/trunk/test/Sema/pragma-attribute-namespace.c<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/pragma-attribute-namespace.c?rev=350572&r1=350571&r2=350572&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/pragma-attribute-namespace.c?rev=350572&r1=350571&r2=350572&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/test/Sema/pragma-attribute-namespace.c
(original)<br>
+++ cfe/trunk/test/Sema/pragma-attribute-namespace.c Mon
Jan 7 13:54:00 2019<br>
@@ -1,5 +1,9 @@<br>
// RUN: %clang_cc1 -fsyntax-only -verify %s<br>
<br>
+#if !__has_feature(pragma_clang_attribute_namespaces)<br>
+#error<br>
+#endif<br>
+<br>
#pragma clang attribute MyNamespace.push
(__attribute__((annotate)), apply_to=function) //
expected-error 2 {{'annotate' attribute}}<br>
<br>
int some_func(); // expected-note{{when applied to this
declaration}}<br>
<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
</blockquote>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
</blockquote></div></div></div></div></div>