[PATCH] Generalized attribute support

[Richard Smith]

On Wed Jan 15 2014 at 3:42:08 AM, Alp Toker <alp at nuanti.com> wrote:

>
> On 15/01/2014 06:04, Nico Weber wrote:
> > Does gcc allow this for C? Is C planning on standardizing this?
>
> The impression I get is that everybody's doing it but nobody's talking
> about it. Yet.
>

Weird. The impression I get is that nobody is doing it (at least, not
publically).


> ISO C is reactionary so if we set a sensible standard there's a
> reasonable shot at getting it adopted. Likewise OpenMP and other
> dialects -- they'll go with the mainstream.
>

The ISO C committee have a long history of taking features from C++,
changing them slightly (in a way which they think is compatible) to meet
their own ideals (in particular, perfect backward compatibility, avoiding
the need for new technology elsewhere in the toolchain, and so on), and
ending up with something subtly incompatible with C++.

If they do standardize an attribute syntax, I would not expect it to
exactly match C++ attributes.

This is also why we should use a name that's already recognised like
> "generalized attributes." Language bodies simply won't accept a foreign
> name like "C++ attributes" -- it has never happened before, given how
> fiercely independent these committees are -- so they'll end up each
> going their own route, choosing their own names. It's a better plan to
> consolidate proactively here.
>
> My view is that it matters because we're working with the people
> designing these standards and they respect our decisions when we put
> time into getting them right.
>
> Of there'll always be those with Richard Smith's point of view that "we
> really don't need to worry about theoretical future C17 or OpenMP
> constructs now" -- but assuming we do care (and I do), these are issues
> that matter.
>

You're quoting me out of context. That was in the context of *how we word a
diagnostic*. This issue is rather different.

What if a future revision of a standard we care about (maybe C, OpenMP,
OpenCL, CUDA, ...) standardizes a *different* meaning for square brackets?
Code that used our extension would be in trouble.

This isn't even purely theoretical -- Objective-C does this, and it is
essentially only by luck that it's possible to disambiguate this fully. As
another example, if C17 took C++'s lambdas but not its attributes, we'd run
into some amount of trouble with expressions like

 int x[ [] { ... } () ];

(which is an ill-formed attribute under the C++11 rules).

> On Tue, Jan 14, 2014 at 5:50 PM, Richard Smith <richard at metafoo.co.uk
> > <mailto:richard at metafoo.co.uk>> wrote:
> >
> >     On Tue, Jan 14, 2014 at 5:47 PM, Richard Smith
> >     <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
> >
> >         On Tue, Jan 14, 2014 at 5:23 PM, Alp Toker <alp at nuanti.com
> >         <mailto:alp at nuanti.com>> 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
> >     cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
> >     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >
> >
>
> --
> http://www.nuanti.com
> the browser experts
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140115/93dca6dd/attachment.html>