On Tue, Jan 14, 2014 at 5:47 PM, Richard Smith <[email protected]>wrote:
> On Tue, Jan 14, 2014 at 5:23 PM, Alp Toker <[email protected]> wrote: > >> This patch generalizes C++11 attributes for use in C and C-like dialects, >> and additionally enables the new syntax as an extension to C11. >> > > Why do you allow this by default in C11? And conversely, why not in C90 / > C99? > I think maybe this was unclear. I'd prefer one of these two options: 1) A -fcxx-attributes argument (or similar) to enable C++ attribute syntax outside C++ (and either do or don't allow them by default in C++98), or 2) C++ attributes available by default in all language modes. I'd prefer the first option (defaulting to following the language standard more strictly) -- I think this would be the first time we enabled a C++ language feature in C modes, if we went with the second option. > If we're going to allow these anywhere by default, C++98 would seem like a > good place to start. I don't believe they introduce any ambiguities outside > of Objective-C(++), and we already disambiguate those cases. (There's an > ambiguity with lambdas, but we don't need to address that until/unless we > allow lambdas in C++98.) > > >> All features are carried forward from C++11, including usage on >> declarations, attributed statements, scoped attribute names, GNU attribute >> aliases and the clang-specific attribute namespace. >> >> A new feature detection macro is provided, breaking from the usual c/cxx >> prefix convention in order to facilitate portable detection in C++ and C >> modes: >> >> __has_feature(attributes) - 1 in C++11, otherwise 0. >> __has_extension(attributes) - 1 in C++11 and C11, otherwise 0. >> > > This is already available as __has_feature(cxx_attributes); using > __has_extension(cxx_attributes) in C would seem to be the right approach > here (we're allowing C++ attributes as an extension in C). This is what we > already do for C99 and C11 features which we accept in C++. > > The new warning flag -W(no-)generalized-attributes suppresses the new >> extension warning in C. The same flag can also be used to selectively >> disable attribute compatibility warnings produced by the pre-existing >> -Wc++98-compat option. >> > > OK, so this is why you wanted us to pick a name for this feature; you're > going to use it as a diagnostic name. I think this should be called > -Wc++-attributes, to match our existing compatible-for-all-time feature > name cxx_attributes. We can add an alias to a better name if we ever need > one, but for now, we're pretty clearly allowing a C++ feature in C, so > calling it "c++-something" makes sense to me. > > Newly added tests have been shared with C++11 where possible to ensure >> consistency between language modes. > > > Does this do the right thing for (for instance) > > struct S { > [[ gnu::aligned(8) ]] int n; > }; > > ? (Structs use different parsing code in C and C++. ) >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
