Initial implementation of C attributes (WG14 N2137)

[aaron.ballman]

Summary

WG14 has demonstrated sincere interest in adding C++-style attributes to C for C2x, and have added the proposal to their SD-3 document tracking features which are possibly desired for the next version of the standard. The proposal has *not* been formally adopted into the working draft (C17 needs to be finalized first), but it is at the stage where having implementation experience is important to the committee.

This patch implements the feature as proposed, but it might make sense to split the patch up, depending on what we think is the correct way to proceed. This patch adds c2x as a new language standard as well as -fc-attributes and -fno-c-attributes flags. The intention is that -std=c2x will enable -fc-attributes once the feature is formally adopted by WG14, but -fc-attributes can be used to enable the functionality in earlier standard modes (but is currently required in order to enable the functionality). fno-c-attributes is provided on the chance that the syntax proposed causes parsing issues for Objective-C and users need a way to work around that; however, such cases should be considered bugs that we need to work around similar to Objective-C++ and C++11-style attributes. The patch also adds support for the deprecated attribute (WG14 N2050), mostly so that I would have an attribute handy to test the semantic functionality. Once the basic syntax is committed, I plan to implement the other attributes: nodiscard (WG14 N2051), fallthrough (WG14 N2052), and maybe_unused (WG14 N2053) in separate patches.

[rsmith]

Accepting this under -std=c2x is premature. We don't even know whether there will be such a standard yet, and this has not been voted into a working draft. But the -f flag form is OK.

include/clang/Driver/Options.td

607

Missing underscore between "fc" and "attributes".

lib/Parse/ParseDecl.cpp

1512

This name should still reference the syntax used, since it is specific to [[...]] attribute syntax. Calling that CXX11 attribute syntax (even when used in C) doesn't seem overly confusing to me. If you want a different name for this, I'd be OK with that, but it should not be simply "Attribute".

[aaron.ballman]

Updated based on Richard's comments and some further discussion on IRC.

[rsmith]

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a separate attribute syntax with a distinct set of valid unqualified attribute names.

include/clang/Basic/LangOptions.def

140

Can we give this a more general name, then enable it under CPlusPlus too? That's what we do for other similar features.

include/clang/Driver/Options.td

607

Hmm. On reflection, if we're going to have a flag to enable C++11 attributes in other language modes, it should probably work in C++98 mode too, so calling this -fc-attributes is probably not the best idea. -fc++11-attributes might make sense, though.

lib/Parse/ParseDecl.cpp

4219

I don't think we can reasonably say what C2x will do. Also, doesn't this reject valid code such as:

struct __attribute__((deprecated)) Foo;

?

lib/Parse/ParseDeclCXX.cpp

3939–3940

This change is unnecessary. kw_alignas is not produced by the lexer in modes where we should not parse it.

3947

[[... in C is not a standards-based attribute list. I'd revert this change too.

3956

Likewise.

[aaron.ballman]

Updates based on review feedback.

[aaron.ballman]

In D37436#867287, @rsmith wrote:

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
separate attribute syntax with a distinct set of valid unqualified attribute names.

I do not think that's the correct approach. These are not C++ attributes (for instance, no using insanity is allowed, :: is a new lexing token in C, etc). Also, I don't think it's a good idea to enable all C++11-style attributes in C mode without giving each attribute some appropriate thought (what does abi_tag *do* in C mode? What happens with _Noreturn vs [[noreturn]] etc). Also, I'm not comfortable adding a bunch of vendor-specific gnu:: attributes that GCC does not implement in C yet.

The goal of this is to get a working implementation of the attribute syntax that WG14 has shown strong support for including in C2x (F: 16, N: 3, A: 1) with this syntax (F: 12, N: 3, A: 4). The experimental part where I need feedback is whether the paper needs to change because of implementation experience. So far, that's not been required. The more we drift from what's proposed in N2137, the less useful the implementation experience will be (esp if we basically turn this into a simple "enable C++ attributes everywhere" flag). I can understand not adding a C2x language mode due to the lack of a working draft, but that lack should not be what drives internal implementation details for the feature -- I think the separation of concerns in this patch is valuable.

include/clang/Basic/LangOptions.def

140

I'm not keen on naming it 'Attributes', but the other names are worse (GeneralAttributes, StandardAttributes). Do you have a suggestion?

include/clang/Driver/Options.td

607

I can't think of a reason why you'd want to control C and C++ attributes separately, so I think it makes sense to add a more general name for this.

I'm definitely not keen on that flag name. I wouldn't be opposed to -fattributes, but that may lead to confusion about other vendor-specific attributes (which we could always decide to use flags like -fdeclspec-attributes etc).

What should happen if a user compiles with -std=c++11 -fno-<whatever>-attributes? Do we want to support such a construct?

lib/Parse/ParseDecl.cpp

4219

Sorry for the lack of context in the patch (TortoiseSVN doesn't make this easy). This has to do with enum specifiers, not struct or unions -- it will reject enum __attribute__((deprecated)) Foo; as not allowing an attribute list *and* as being a forward reference in C++ mode, but accepts in C mode.

lib/Parse/ParseDeclCXX.cpp

3939–3940

Ah, good to know. I'll remove.

3956

I'll add a test for this to ensure we don't accidentally allow it in C mode.

[hfinkel]

In D37436#867965, @aaron.ballman wrote:

In D37436#867287, @rsmith wrote:

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
separate attribute syntax with a distinct set of valid unqualified attribute names.

I do not think that's the correct approach. These are not C++ attributes (for instance, no using insanity is allowed, :: is a new lexing token in C, etc). Also, I don't think it's a good idea to enable all C++11-style attributes in C mode without giving each attribute some appropriate thought (what does abi_tag *do* in C mode? What happens with _Noreturn vs [[noreturn]] etc). Also, I'm not comfortable adding a bunch of vendor-specific gnu:: attributes that GCC does not implement in C yet.

On this last point, I disagree. Implementation experience is about all of the messy things that occur in production. In production, if we have this syntax, then we'll end up enabling it for a bunch of vendor-specific attributes. Do you think that we wouldn't? N2137 specifically talks about this as a use case. If so, this will include gnu:: attributes that we have in Clang (even if GCC does not implement them). From my perspective, lack of consistency here between Clang's C and C++ modes is much more problematic than a lack of consistency between what Clang and GCC implement.

[aaron.ballman]

In D37436#868295, @hfinkel wrote:

In D37436#867965, @aaron.ballman wrote:

In D37436#867287, @rsmith wrote:

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
separate attribute syntax with a distinct set of valid unqualified attribute names.

I do not think that's the correct approach. These are not C++ attributes (for instance, no using insanity is allowed, :: is a new lexing token in C, etc). Also, I don't think it's a good idea to enable all C++11-style attributes in C mode without giving each attribute some appropriate thought (what does abi_tag *do* in C mode? What happens with _Noreturn vs [[noreturn]] etc). Also, I'm not comfortable adding a bunch of vendor-specific gnu:: attributes that GCC does not implement in C yet.

On this last point, I disagree. Implementation experience is about all of the messy things that occur in production. In production, if we have this syntax, then we'll end up enabling it for a bunch of vendor-specific attributes. Do you think that we wouldn't?

I'm sure we would. Also, FWIW, I was planning to traverse the attributes we implement to find which clang-specific C++ attributes would make sense to also enable as a follow-up patch once the syntax is in.

N2137 specifically talks about this as a use case. If so, this will include gnu:: attributes that we have in Clang (even if GCC does not implement them).

Eventually, yes, but it seems like a problem to implement something under that vendor namespace when the vendor themselves do not. I think it would be really unfortunate were GCC to add a C++ attribute named [[clang::frobble]] that Clang does not implement, and I don't see this case as being all that different. My belief is that GCC will eventually elect to make most of these attributes available in C mode and that's an appropriate time for us to do the same for their vendor namespace.

From my perspective, lack of consistency here between Clang's C and C++ modes is much more problematic than a lack of consistency between what Clang and GCC implement.

From my perspective, they're both problems in their own right. To me (and maybe I'm weird with this line of reasoning), the only reasonable time to implement an attribute under another vendor's attribute namespace is when you are promising your users that you will attempt to match the owning vendor's semantics for that attribute. A case could be made here that the owning vendor *has* implemented that attribute (since they have in C++), but I'm not too comfortable *assuming* that the GCC folks are okay with this since they don't implement the feature syntax in C yet.

That said, I'm happy to ask Jason at the meetings in Albuquerque to explore the idea -- but I don't think it should hold up this patch, especially since we have our own vendor attributes we can use for gaining experience.

[hfinkel]

In D37436#868333, @aaron.ballman wrote:

In D37436#868295, @hfinkel wrote:

In D37436#867965, @aaron.ballman wrote:

In D37436#867287, @rsmith wrote:

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
separate attribute syntax with a distinct set of valid unqualified attribute names.

I do not think that's the correct approach. These are not C++ attributes (for instance, no using insanity is allowed, :: is a new lexing token in C, etc). Also, I don't think it's a good idea to enable all C++11-style attributes in C mode without giving each attribute some appropriate thought (what does abi_tag *do* in C mode? What happens with _Noreturn vs [[noreturn]] etc). Also, I'm not comfortable adding a bunch of vendor-specific gnu:: attributes that GCC does not implement in C yet.

On this last point, I disagree. Implementation experience is about all of the messy things that occur in production. In production, if we have this syntax, then we'll end up enabling it for a bunch of vendor-specific attributes. Do you think that we wouldn't?

I'm sure we would. Also, FWIW, I was planning to traverse the attributes we implement to find which clang-specific C++ attributes would make sense to also enable as a follow-up patch once the syntax is in.

N2137 specifically talks about this as a use case. If so, this will include gnu:: attributes that we have in Clang (even if GCC does not implement them).

Eventually, yes, but it seems like a problem to implement something under that vendor namespace when the vendor themselves do not. I think it would be really unfortunate were GCC to add a C++ attribute named [[clang::frobble]] that Clang does not implement, and I don't see this case as being all that different. My belief is that GCC will eventually elect to make most of these attributes available in C mode and that's an appropriate time for us to do the same for their vendor namespace.

From my perspective, lack of consistency here between Clang's C and C++ modes is much more problematic than a lack of consistency between what Clang and GCC implement.

From my perspective, they're both problems in their own right. To me (and maybe I'm weird with this line of reasoning), the only reasonable time to implement an attribute under another vendor's attribute namespace is when you are promising your users that you will attempt to match the owning vendor's semantics for that attribute. A case could be made here that the owning vendor *has* implemented that attribute (since they have in C++), but I'm not too comfortable *assuming* that the GCC folks are okay with this since they don't implement the feature syntax in C yet.

That said, I'm happy to ask Jason at the meetings in Albuquerque to explore the idea -- but I don't think it should hold up this patch, especially since we have our own vendor attributes we can use for gaining experience.

I certainly understand your perspective, but this is an orthogonal concern. If this is something that Clang does, then it should do it consistently. If you'd like us not to support gnu:: attributes that GCC itself does not support, and that's something that we currently do in C++, then please submit a patch to fix that for all language modes. It should not differ between language modes.

Is the problem here that we're treating gnu::, not as a vendor prefix, but as generic escape hatch to get to anything generally provided via GCC-attribute syntax (which many compilers, including ours, have extended with attributes that GCC does not itself support)?

[hfinkel]

Also, please post a full-context patch.

[aaron.ballman]

In D37436#869350, @hfinkel wrote:

In D37436#868333, @aaron.ballman wrote:

In D37436#868295, @hfinkel wrote:

In D37436#867965, @aaron.ballman wrote:

In D37436#867287, @rsmith wrote:

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
separate attribute syntax with a distinct set of valid unqualified attribute names.

I do not think that's the correct approach. These are not C++ attributes (for instance, no using insanity is allowed, :: is a new lexing token in C, etc). Also, I don't think it's a good idea to enable all C++11-style attributes in C mode without giving each attribute some appropriate thought (what does abi_tag *do* in C mode? What happens with _Noreturn vs [[noreturn]] etc). Also, I'm not comfortable adding a bunch of vendor-specific gnu:: attributes that GCC does not implement in C yet.

On this last point, I disagree. Implementation experience is about all of the messy things that occur in production. In production, if we have this syntax, then we'll end up enabling it for a bunch of vendor-specific attributes. Do you think that we wouldn't?

I'm sure we would. Also, FWIW, I was planning to traverse the attributes we implement to find which clang-specific C++ attributes would make sense to also enable as a follow-up patch once the syntax is in.

N2137 specifically talks about this as a use case. If so, this will include gnu:: attributes that we have in Clang (even if GCC does not implement them).

Eventually, yes, but it seems like a problem to implement something under that vendor namespace when the vendor themselves do not. I think it would be really unfortunate were GCC to add a C++ attribute named [[clang::frobble]] that Clang does not implement, and I don't see this case as being all that different. My belief is that GCC will eventually elect to make most of these attributes available in C mode and that's an appropriate time for us to do the same for their vendor namespace.

From my perspective, lack of consistency here between Clang's C and C++ modes is much more problematic than a lack of consistency between what Clang and GCC implement.

From my perspective, they're both problems in their own right. To me (and maybe I'm weird with this line of reasoning), the only reasonable time to implement an attribute under another vendor's attribute namespace is when you are promising your users that you will attempt to match the owning vendor's semantics for that attribute. A case could be made here that the owning vendor *has* implemented that attribute (since they have in C++), but I'm not too comfortable *assuming* that the GCC folks are okay with this since they don't implement the feature syntax in C yet.

That said, I'm happy to ask Jason at the meetings in Albuquerque to explore the idea -- but I don't think it should hold up this patch, especially since we have our own vendor attributes we can use for gaining experience.

I certainly understand your perspective, but this is an orthogonal concern. If this is something that Clang does, then it should do it consistently. If you'd like us not to support gnu:: attributes that GCC itself does not support, and that's something that we currently do in C++, then please submit a patch to fix that for all language modes. It should not differ between language modes.

Is the problem here that we're treating gnu::, not as a vendor prefix, but as generic escape hatch to get to anything generally provided via GCC-attribute syntax (which many compilers, including ours, have extended with attributes that GCC does not itself support)?

I definitely agree that we want to be self-consistent, so thank you for helping me understand where you're coming from.

I've been very consistent in rejecting patches that add C++ attributes to the gnu namespace unless GCC also implements them. This most often comes up as a misunderstanding of when to use the GNU<> (just provides support for __attribute__(())) spelling and when to use the GCC<> (provides support for both __attribute__(()) and [[gnu::]]) spelling. If you know of any attributes that we've put into the gnu namespace (perhaps through a GCC spelling) that are not supported by GCC, I'd like to know so that I can fix them. FWIW, I took a quick look through Attr.td this morning and we have zero attributes explicitly in the gnu namespace (CXX11<"gnu", "blah">), and I spot-checked the GCC spellings and did not find any that were not also documented by GCC.

We have certainly added GNU-style attributes to Clang that GCC does not support, and that's totally fine (there is no vendor namespace there which we could use). I would absolutely welcome discussion as to whether we want to expose those through a C++11 attribute under the clang namespace (we've done that in a handful of cases, but have not been consistent about it because some of those attributes don't apply to C++ code). However, I think that's an orthogonal patch to this one (and one I would really like to explore once we have a consistent C and C++ attribute syntax). Basically, I think that someday we may want to add a CLANG<> spelling that exposes the attribute as __attribute__(()) and [[clang::]] (in both C and C++) and use that similar to how we handle GCC<>.

Also, please post a full-context patch.

Ugh. I swear TortoiseSVN used to handle this properly for me. I'll re-upload with full context.

[aaron.ballman]

Added full context, no other changes from previous patch.

[hfinkel]

In D37436#869445, @aaron.ballman wrote:

In D37436#869350, @hfinkel wrote:

In D37436#868333, @aaron.ballman wrote:

In D37436#868295, @hfinkel wrote:

In D37436#867965, @aaron.ballman wrote:

In D37436#867287, @rsmith wrote:

If this is just supposed to be an experiment to get feedback on the feature, then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
separate attribute syntax with a distinct set of valid unqualified attribute names.

I do not think that's the correct approach. These are not C++ attributes (for instance, no using insanity is allowed, :: is a new lexing token in C, etc). Also, I don't think it's a good idea to enable all C++11-style attributes in C mode without giving each attribute some appropriate thought (what does abi_tag *do* in C mode? What happens with _Noreturn vs [[noreturn]] etc). Also, I'm not comfortable adding a bunch of vendor-specific gnu:: attributes that GCC does not implement in C yet.

On this last point, I disagree. Implementation experience is about all of the messy things that occur in production. In production, if we have this syntax, then we'll end up enabling it for a bunch of vendor-specific attributes. Do you think that we wouldn't?

I'm sure we would. Also, FWIW, I was planning to traverse the attributes we implement to find which clang-specific C++ attributes would make sense to also enable as a follow-up patch once the syntax is in.

N2137 specifically talks about this as a use case. If so, this will include gnu:: attributes that we have in Clang (even if GCC does not implement them).

Eventually, yes, but it seems like a problem to implement something under that vendor namespace when the vendor themselves do not. I think it would be really unfortunate were GCC to add a C++ attribute named [[clang::frobble]] that Clang does not implement, and I don't see this case as being all that different. My belief is that GCC will eventually elect to make most of these attributes available in C mode and that's an appropriate time for us to do the same for their vendor namespace.

From my perspective, lack of consistency here between Clang's C and C++ modes is much more problematic than a lack of consistency between what Clang and GCC implement.

From my perspective, they're both problems in their own right. To me (and maybe I'm weird with this line of reasoning), the only reasonable time to implement an attribute under another vendor's attribute namespace is when you are promising your users that you will attempt to match the owning vendor's semantics for that attribute. A case could be made here that the owning vendor *has* implemented that attribute (since they have in C++), but I'm not too comfortable *assuming* that the GCC folks are okay with this since they don't implement the feature syntax in C yet.

That said, I'm happy to ask Jason at the meetings in Albuquerque to explore the idea -- but I don't think it should hold up this patch, especially since we have our own vendor attributes we can use for gaining experience.

I certainly understand your perspective, but this is an orthogonal concern. If this is something that Clang does, then it should do it consistently. If you'd like us not to support gnu:: attributes that GCC itself does not support, and that's something that we currently do in C++, then please submit a patch to fix that for all language modes. It should not differ between language modes.

Is the problem here that we're treating gnu::, not as a vendor prefix, but as generic escape hatch to get to anything generally provided via GCC-attribute syntax (which many compilers, including ours, have extended with attributes that GCC does not itself support)?

I definitely agree that we want to be self-consistent, so thank you for helping me understand where you're coming from.

I've been very consistent in rejecting patches that add C++ attributes to the gnu namespace unless GCC also implements them. This most often comes up as a misunderstanding of when to use the GNU<> (just provides support for __attribute__(())) spelling and when to use the GCC<> (provides support for both __attribute__(()) and [[gnu::]]) spelling. If you know of any attributes that we've put into the gnu namespace (perhaps through a GCC spelling) that are not supported by GCC, I'd like to know so that I can fix them. FWIW, I took a quick look through Attr.td this morning and we have zero attributes explicitly in the gnu namespace (CXX11<"gnu", "blah">), and I spot-checked the GCC spellings and did not find any that were not also documented by GCC.

We have certainly added GNU-style attributes to Clang that GCC does not support, and that's totally fine (there is no vendor namespace there which we could use). I would absolutely welcome discussion as to whether we want to expose those through a C++11 attribute under the clang namespace (we've done that in a handful of cases, but have not been consistent about it because some of those attributes don't apply to C++ code). However, I think that's an orthogonal patch to this one (and one I would really like to explore once we have a consistent C and C++ attribute syntax). Basically, I think that someday we may want to add a CLANG<> spelling that exposes the attribute as __attribute__(()) and [[clang::]] (in both C and C++) and use that similar to how we handle GCC<>.

I think that I misunderstood your concern. Let me see if I can summarize your position: You believe that, when GCC implements this syntax in C, they will audit their attributes and not support all of their existing gnu:: attributes in C. You only want us to support these when we know what that list will be (which we don't yet). Is that correct?

Also, please post a full-context patch.

Ugh. I swear TortoiseSVN used to handle this properly for me. I'll re-upload with full context.

[aaron.ballman]

In D37436#869462, @hfinkel wrote:

I think that I misunderstood your concern. Let me see if I can summarize your position: You believe that, when GCC implements this syntax in C, they will audit their attributes and not support all of their existing gnu:: attributes in C. You only want us to support these when we know what that list will be (which we don't yet). Is that correct?

Yes, that is correct.

[hfinkel]

In D37436#869467, @aaron.ballman wrote:

In D37436#869462, @hfinkel wrote:

I think that I misunderstood your concern. Let me see if I can summarize your position: You believe that, when GCC implements this syntax in C, they will audit their attributes and not support all of their existing gnu:: attributes in C. You only want us to support these when we know what that list will be (which we don't yet). Is that correct?

Yes, that is correct.

Okay. A large fraction of the number of attributes we'll want to use are going to fall into this category (because Clang doesn't have its own attributes, but copied GCC's, for many things). I don't think we'll get good implementation feedback until we have this figured out. If we can't sync with GCC soon, I suggest just making a reasonable guess. My first choice would be to just allowing everything, and then we can see what people found to be useful and why. Our experience here can also provide feedback to GCC (and we can always update late if needed - it is still an experimental feature).

[aaron.ballman]

In D37436#869851, @hfinkel wrote:

In D37436#869467, @aaron.ballman wrote:

In D37436#869462, @hfinkel wrote:

I think that I misunderstood your concern. Let me see if I can summarize your position: You believe that, when GCC implements this syntax in C, they will audit their attributes and not support all of their existing gnu:: attributes in C. You only want us to support these when we know what that list will be (which we don't yet). Is that correct?

Yes, that is correct.

Okay. A large fraction of the number of attributes we'll want to use are going to fall into this category (because Clang doesn't have its own attributes, but copied GCC's, for many things). I don't think we'll get good implementation feedback until we have this figured out. If we can't sync with GCC soon, I suggest just making a reasonable guess. My first choice would be to just allowing everything, and then we can see what people found to be useful and why. Our experience here can also provide feedback to GCC (and we can always update late if needed - it is still an experimental feature).

I think this direction is a reasonable one, but not for the initial syntax patch. I would prefer to be conservative and get the basic syntax in first. My plan is that once the syntax is available, I would start adding more attributes, starting with the ones proposed to WG14, followed by the existing C++ ones in the clang namespace. I think the gnu attributes would likely be immediately following the clang ones, so they're definitely a high priority for me to support.

Btw, because I wasn't explicit about this, we're in violent agreement that getting implementation experience about how well we can share attributes between C and C++ code bases is also an important question to answer.

[rsmith]

In D37436#869851, @hfinkel wrote:

A large fraction of the number of attributes we'll want to use are going to fall into this category (because Clang doesn't have its own attributes, but copied GCC's, for many things). I don't think we'll get good implementation feedback until we have this figured out. If we can't sync with GCC soon, I suggest just making a reasonable guess. My first choice would be to just allowing everything, and then we can see what people found to be useful and why. Our experience here can also provide feedback to GCC (and we can always update late if needed - it is still an experimental feature).

I think I would be more comfortable taking those attributes that we want to support in C and making them available in the clang:: attribute namespace (across all languages). Because GCC has distinct C and C++ parsers (sharing some, but not all, code) there are often differences between how they handle the same construct in C and C++ mode, and accepting all [[gnu::something]] attributes in C mode seems likely to create incompatibilities, even if GCC decides that all __attribute__s should be available as [[gnu::x]] in C.

Also, your wording paper appears to allow things like

struct [[foo]] S *p; // ok in c n2137, ill-formed in c++
struct T {};
int n = sizeof(struct [[foo]] T); // ok in c n2137, ill-formed in c++

You don't seem to implement those changes; are they bugs in the wording paper? (The relevant C++ rule is [dcl.type.elab]p1: "An attribute-specifier-seq shall not appear in an elaborated-type-specifier unless the latter is the sole constituent of a declaration." Neither of the above cases is prohibited by n2137's 6.7.2.1/6: "An attribute-specifier-seq shall not appear in a struct-or-union-specifier of the form struct-or-union attribute-specifier-seqopt identifier if the struct-or-union-specifier is an incomplete type used in a parameter-declaration or type-name." -- the first case is not in a parameter-declaration or type-name and the second case is not an incomplete type -- and no other rule seems to disallow this.)

include/clang/Basic/LangOptions.def

140

It's kind of long, but how about DoubleSquareBracketAttributes

include/clang/Driver/Options.td

607

I wouldn't recommend anyone actually does that, but I'd expect clang to respect their wishes if they ask for it, just like we do for -fms-extensions -fno-declspec.

lib/Parse/ParseDecl.cpp

4219

OK, but GCC accepts that with a warning in the friend case, and this would also seem to reject valid constructs such as

enum __attribute__((deprecated)) Foo : int;

But... C permits neither the TUK_Declaration nor TUK_Friend cases for enums. The change in your wording proposal appears to be for the TUK_Reference case instead, which you didn't change here.

[aaron.ballman]

In D37436#870305, @rsmith wrote:

Also, your wording paper appears to allow things like

struct [[foo]] S *p; // ok in c n2137, ill-formed in c++
struct T {};
int n = sizeof(struct [[foo]] T); // ok in c n2137, ill-formed in c++

You don't seem to implement those changes; are they bugs in the wording paper?

These are bugs in the wording paper which I think I've corrected for the upcoming draft (no N number yet).

(The relevant C++ rule is [dcl.type.elab]p1: "An attribute-specifier-seq shall not appear in an elaborated-type-specifier unless the latter is the sole constituent of a declaration." Neither of the above cases is prohibited by n2137's 6.7.2.1/6: "An attribute-specifier-seq shall not appear in a struct-or-union-specifier of the form struct-or-union attribute-specifier-seqopt identifier if the struct-or-union-specifier is an incomplete type used in a parameter-declaration or type-name." -- the first case is not in a parameter-declaration or type-name and the second case is not an incomplete type -- and no other rule seems to disallow this.)

Yeah, I recognized that after the last meeting and have modified 6.7.2.1p7 to be:

7 An attribute-specifier-seq shall not appear in a struct-or-union-specifier without a struct-declaration-list, except in a declaration of the form:
    struct-or-union attribute-specifier-seq identifier ;
The attributes in the attribute-specifier-seq, if any, are thereafter considered attributes of the struct or union whenever it is named.

I think that resolves both of your concerns, but does it resolve all similar concerns?

include/clang/Basic/LangOptions.def

140

I can't think of anything better, so I'll go with that.

include/clang/Driver/Options.td

607

Would you be okay with -fattributes as the flag name, or do you prefer -fdouble-square-bracket-attributes?

lib/Parse/ParseDecl.cpp

4219

Ah, okay, thank you for the help there, I'll correct (and add another test case, because your example is rejected when passing -fc-attributes).

[aaron.ballman]

Updated based on review feedback.

• Rename CAttributes to DoubleSquareBracketAttributes
• Added Objective-C test cases to demonstrate no regressed behavior (based on a use-case pointed out during review)
• Fixed regression with GNU-style attributes in enumerations

I still need to rename the cc1 flag, pending agreement on the name.

[aaron.ballman]

In D37436#871117, @aaron.ballman wrote:

Updated based on review feedback.

• Rename CAttributes to DoubleSquareBracketAttributes
• Added Objective-C test cases to demonstrate no regressed behavior (based on a use-case pointed out during review)
• Fixed regression with GNU-style attributes in enumerations

I still need to rename the cc1 flag, pending agreement on the name.

Ping -- the last outstanding issue that I'm aware of is the cc1 flag name, do you have a preference there, Richard? If not, I'll be going with the verbose -fdouble-square-bracket-attributes.

[aaron.ballman]

In D37436#881363, @aaron.ballman wrote:

In D37436#871117, @aaron.ballman wrote:

Updated based on review feedback.

• Rename CAttributes to DoubleSquareBracketAttributes
• Added Objective-C test cases to demonstrate no regressed behavior (based on a use-case pointed out during review)
• Fixed regression with GNU-style attributes in enumerations

I still need to rename the cc1 flag, pending agreement on the name.

Ping -- the last outstanding issue that I'm aware of is the cc1 flag name, do you have a preference there, Richard? If not, I'll be going with the verbose -fdouble-square-bracket-attributes.

Post-cppcon-ping.

[rsmith]

Mostly looks good, other than the regression in enum parsing.

clang/include/clang/Basic/LangOptions.def

140 ↗

(On Diff #115279)

I would probably singularize this to DoubleSquareBracketAttributes. But I'm happy with either.

clang/lib/Parse/ParseDecl.cpp

4223–4225 ↗

(On Diff #115279)

This change still looks wrong to me. C++11 attributes are not prohibited in an opaque-enum-declaration.

5973–5974 ↗

(On Diff #115279)

Do you anticipate people trying this? Is the concern here that a function declarator can normally be followed by attributes, and so consistency might imply that we allow attributes on the function declarator after an identifier-list instead?

clang/lib/Parse/ParseDeclCXX.cpp

3855–3857 ↗

(On Diff #115279)

This uses AS_C2x if -fdouble-square-bracket-attributes is enabled in C++98, which is probably not the desired behavior.

3913 ↗

(On Diff #115279)

Accidental lowercasing of an S?

clang/lib/Parse/ParseTentative.cpp

592 ↗

(On Diff #115279)

This change is redundant. We wouldn't lex a kw_alignas token outside C++11.

clang/test/CXX/dcl.dcl/dcl.attr/dcl.align/p6.cpp

31 ↗

(On Diff #115279)

This looks like the bug I pointed out above. This is a regression; this code is valid.

include/clang/Driver/Options.td

607

I think -fattributes is problematically non-specific. I think it would be surprising that -fno-attributes does not turn off support for __attribute__, for example.

[aaron.ballman]

Corrected review feedback from Richard.

• Changed the cc1 option to -fdouble-square-bracket-attributes
• Corrected regression with opaque-enum-declarations

clang/lib/Parse/ParseDecl.cpp

5973–5974 ↗

(On Diff #115279)

I don't anticipate this being a common thing for people to try, but it is to prevent an ambiguity:

void fp(a, b) [[foo]] int a, b; { }

Does [[foo]] appertain to the function type or to the declarations a and b. N2165 prohibits attributes from appearing in this location.

clang/lib/Parse/ParseTentative.cpp

592 ↗

(On Diff #115279)

Ah, I thought that we would hit this case for _Alignas as well, but I see that's a different keyword. Just to double-check -- we don't expect -fdouble-square-bracket-attributes to enable alignas in C++98, correct?

[aaron.ballman]

Ping.

[rsmith]

Thanks, LGTM :)

../llvm/tools/clang/include/clang/Driver/Options.td

609–616 ↗

(On Diff #118141)

This is not formatted how we normally format tablegen files.

../llvm/tools/clang/lib/Parse/ParseDecl.cpp

4422 ↗

(On Diff #118141)

Is this warning appropriate in C? I don't recall whether your proposal permits attributes on enumerators or not.

... in fact, this warning is completely wrong. Fixed in r315784. This should presumably be guarded by an if (getLangOpts().CPlusPlus) with your change, though.

../llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp

3856–3857 ↗

(On Diff #118141)

I think you can simplify this to LO.CPlusPlus, because LO.DoubleSquareBracketAttributes should always be true if we get here. (Right?)

clang/lib/Parse/ParseTentative.cpp

592 ↗

(On Diff #115279)

Right, I would not expect it to affect the set of available keywords.

[aaron.ballman]

I've commit in r315856, thank you for the reviews!

../llvm/tools/clang/include/clang/Driver/Options.td

609–616 ↗

(On Diff #118141)

I'll fix it up -- I think this was clang-formatted.

../llvm/tools/clang/lib/Parse/ParseDecl.cpp

4422 ↗

(On Diff #118141)

Is this warning appropriate in C? I don't recall whether your proposal permits attributes on enumerators or not.

Yes, my proposal allows attributes on enumerators. I will fix up with your merge, thanks!

../llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp

3856–3857 ↗

(On Diff #118141)

Correct, I've simplified.

include/clang/Basic/Attr.td

   string Namespace = namespace;
   int Version = version;
 }
+class C2x<string namespace, string name> : Spelling<name, "C2x"> {
+  string Namespace = namespace;
+}
+
 class Keyword<string name> : Spelling<name, "Keyword">;
 class Pragma<string namespace, string name> : Spelling<name, "Pragma"> {
   string Namespace = namespace;

 
 def Deprecated : InheritableAttr {
   let Spellings = [GCC<"deprecated">, Declspec<"deprecated">,
-                   CXX11<"","deprecated", 201309>];
+                   CXX11<"","deprecated", 201309>, C2x<"", "deprecated">];
   let Args = [StringArgument<"Message", 1>,
               // An optional string argument that enables us to provide a
               // Fix-It.

include/clang/Basic/Attributes.h

   Microsoft,
   // Is the identifier known as a C++-style attribute?
   CXX,
+  // Is the identifier known as a C-style attribute?
+  C,
   // Is the identifier known as a pragma attribute?
   Pragma
 };

include/clang/Basic/LangOptions.def

 LANGOPT(CoroutinesTS      , 1, 0, "C++ coroutines TS")
 LANGOPT(RelaxedTemplateTemplateArgs, 1, 0, "C++17 relaxed matching of template template arguments")
 
+LANGOPT(CAttributes       , 1, 0, "'[[]]' attributes extension to C")
+
 BENIGN_LANGOPT(ThreadsafeStatics , 1, 1, "thread-safe static initializers")
 LANGOPT(POSIXThreads      , 1, 0, "POSIX thread support")
 LANGOPT(Blocks            , 1, 0, "blocks extension to C")

include/clang/Driver/Options.td

 def fast : Flag<["-"], "fast">, Group<f_Group>;
 def fasynchronous_unwind_tables : Flag<["-"], "fasynchronous-unwind-tables">, Group<f_Group>;
 
+def fc_attributes : Flag<["-"], "fc-attributes">, Group<f_Group>,
+  Flags<[DriverOption, CC1Option]>, HelpText<"Enable '[[]]' attributes in C">;
+def fno_c_attributes : Flag<["-"], "fno-c-attributes">, Group<f_Group>,
+  Flags<[DriverOption]>, HelpText<"Disable '[[]]' attributes in C">;
+
 def fautolink : Flag <["-"], "fautolink">, Group<f_Group>;
 def fno_autolink : Flag <["-"], "fno-autolink">, Group<f_Group>,
   Flags<[DriverOption, CC1Option]>,

include/clang/Parse/Parser.h

 private:
   void ParseBlockId(SourceLocation CaretLoc);
 
-  // Check for the start of a C++11 attribute-specifier-seq in a context where
-  // an attribute is not allowed.
+  /// Are C++11 or C2x attributes enabled?
+  bool standardAttributesAllowed() const {
+    const LangOptions &LO = getLangOpts();
+    return LO.CPlusPlus11 || LO.CAttributes;
+  }
+
+  // Check for the start of an attribute-specifier-seq in a context where an
+  // attribute is not allowed.
   bool CheckProhibitedCXX11Attribute() {
     assert(Tok.is(tok::l_square));
-    if (!getLangOpts().CPlusPlus11 || NextToken().isNot(tok::l_square))
+    if (!standardAttributesAllowed() || NextToken().isNot(tok::l_square))
       return false;
     return DiagnoseProhibitedCXX11Attribute();
   }
+
   bool DiagnoseProhibitedCXX11Attribute();
   void CheckMisplacedCXX11Attribute(ParsedAttributesWithRange &Attrs,
                                     SourceLocation CorrectLocation) {
-    if (!getLangOpts().CPlusPlus11)
+    if (!standardAttributesAllowed())
       return;
     if ((Tok.isNot(tok::l_square) || NextToken().isNot(tok::l_square)) &&
         Tok.isNot(tok::kw_alignas))

   }
   void DiagnoseProhibitedAttributes(ParsedAttributesWithRange &attrs);
 
-  // Forbid C++11 attributes that appear on certain syntactic 
-  // locations which standard permits but we don't supported yet, 
-  // for example, attributes appertain to decl specifiers.
+  // Forbid C++11 and C2x attributes that appear on certain syntactic locations
+  // which standard permits but we don't supported yet, for example, attributes
+  // appertain to decl specifiers.
   void ProhibitCXX11Attributes(ParsedAttributesWithRange &Attrs,
                                unsigned DiagID);
 
-  /// \brief Skip C++11 attributes and return the end location of the last one.
+  /// \brief Skip C++11 and C2x attributes and return the end location of the
+  /// last one.
   /// \returns SourceLocation() if there are no attributes.
   SourceLocation SkipCXX11Attributes();
 
-  /// \brief Diagnose and skip C++11 attributes that appear in syntactic
+  /// \brief Diagnose and skip C++11 and C2x attributes that appear in syntactic
   /// locations where attributes are not allowed.
   void DiagnoseAndSkipCXX11Attributes();
 

                           AttributeList::Syntax Syntax);
 
   void MaybeParseCXX11Attributes(Declarator &D) {
-    if (getLangOpts().CPlusPlus11 && isCXX11AttributeSpecifier()) {
+    if (standardAttributesAllowed() && isCXX11AttributeSpecifier()) {
       ParsedAttributesWithRange attrs(AttrFactory);
       SourceLocation endLoc;
       ParseCXX11Attributes(attrs, &endLoc);

   }
   void MaybeParseCXX11Attributes(ParsedAttributes &attrs,
                                  SourceLocation *endLoc = nullptr) {
-    if (getLangOpts().CPlusPlus11 && isCXX11AttributeSpecifier()) {
+    if (standardAttributesAllowed() && isCXX11AttributeSpecifier()) {
       ParsedAttributesWithRange attrsWithRange(AttrFactory);
       ParseCXX11Attributes(attrsWithRange, endLoc);
       attrs.takeAllFrom(attrsWithRange);

   void MaybeParseCXX11Attributes(ParsedAttributesWithRange &attrs,
                                  SourceLocation *endLoc = nullptr,
                                  bool OuterMightBeMessageSend = false) {
-    if (getLangOpts().CPlusPlus11 &&
-        isCXX11AttributeSpecifier(false, OuterMightBeMessageSend))
+    if (standardAttributesAllowed() &&
       ParseCXX11Attributes(attrs, endLoc);
   }
 

                                     SourceLocation *EndLoc = nullptr);
   void ParseCXX11Attributes(ParsedAttributesWithRange &attrs,
                             SourceLocation *EndLoc = nullptr);
-  /// \brief Parses a C++-style attribute argument list. Returns true if this
-  /// results in adding an attribute to the ParsedAttributes list.
+  /// \brief Parses a C++11 (or C2x)-style attribute argument list. Returns true
+  /// if this results in adding an attribute to the ParsedAttributes list.
   bool ParseCXX11AttributeArgs(IdentifierInfo *AttrName,
                                SourceLocation AttrNameLoc,
                                ParsedAttributes &Attrs, SourceLocation *EndLoc,

include/clang/Sema/AttributeList.h

     AS_GNU,
     /// [[...]]
     AS_CXX11,
+    /// [[...]]
+    AS_C2x,
     /// __declspec(...)
     AS_Declspec,
     /// [uuid("...")] class Foo

   bool isCXX11Attribute() const {
     return SyntaxUsed == AS_CXX11 || isAlignasAttribute();
   }
+  bool isC2xAttribute() const {
+    return SyntaxUsed == AS_C2x;
+  }
   bool isKeywordAttribute() const {
     return SyntaxUsed == AS_Keyword || SyntaxUsed == AS_ContextSensitiveKeyword;
   }

lib/Frontend/CompilerInvocation.cpp

     && Opts.OpenCLVersion >= 200);
   Opts.BlocksRuntimeOptional = Args.hasArg(OPT_fblocks_runtime_optional);
   Opts.CoroutinesTS = Args.hasArg(OPT_fcoroutines_ts);
+  Opts.CAttributes = Args.hasArg(OPT_fc_attributes);
   Opts.ModulesTS = Args.hasArg(OPT_fmodules_ts);
   Opts.Modules = Args.hasArg(OPT_fmodules) || Opts.ModulesTS;
   Opts.ModulesStrictDeclUse = Args.hasArg(OPT_fmodules_strict_decluse);

lib/Lex/Lexer.cpp

     if (LangOpts.Digraphs && Char == '>') {
       Kind = tok::r_square; // ':>' -> ']'
       CurPtr = ConsumeChar(CurPtr, SizeTmp, Result);
-    } else if (LangOpts.CPlusPlus && Char == ':') {
+    } else if ((LangOpts.CPlusPlus || LangOpts.CAttributes) && Char == ':') {
       Kind = tok::coloncolon;
       CurPtr = ConsumeChar(CurPtr, SizeTmp, Result);
     } else {

lib/Parse/ParseDecl.cpp

 
     case tok::l_square:
     case tok::kw_alignas:
-      if (!getLangOpts().CPlusPlus11 || !isCXX11AttributeSpecifier())
+      if (!standardAttributesAllowed() || !isCXX11AttributeSpecifier())
         goto DoneWithDeclSpec;
 
       ProhibitAttributes(attrs);

 /// semicolon.
 ///
 ///       struct-declaration:
-///         specifier-qualifier-list struct-declarator-list
+/// [C2x]   attributes-specifier-seq[opt]
+///           specifier-qualifier-list struct-declarator-list
 /// [GNU]   __extension__ struct-declaration
 /// [GNU]   specifier-qualifier-list
 ///       struct-declarator-list:

     return ParseStructDeclaration(DS, FieldsCallback);
   }
 
+  // Parse leading attributes.
+  ParsedAttributesWithRange Attrs(AttrFactory);
+  MaybeParseCXX11Attributes(Attrs);
+  DS.takeAttributesFrom(Attrs);
+
   // Parse the common specifier-qualifiers-list piece.
   ParseSpecifierQualifierList(DS);
 

       PP.EnterToken(Tok);
       Tok.setKind(tok::semi);
     }
+
+    // Attributes are prohibited in this location in C2x (and forward
+    // declarations are prohibited in C++).
+    ProhibitAttributes(attrs);
   } else {
     TUK = Sema::TUK_Reference;
   }

     ParsedAttributesWithRange attrs(AttrFactory);
     MaybeParseGNUAttributes(attrs);
     ProhibitAttributes(attrs); // GNU-style attributes are prohibited.
-    if (getLangOpts().CPlusPlus11 && isCXX11AttributeSpecifier()) {
+    if (standardAttributesAllowed() && isCXX11AttributeSpecifier()) {
       if (!getLangOpts().CPlusPlus1z)
         Diag(Tok.getLocation(), diag::warn_cxx14_compat_attribute)
             << 1 /*enumerator*/;

     DeclSpec &DS, unsigned AttrReqs, bool AtomicAllowed,
     bool IdentifierRequired,
     Optional<llvm::function_ref<void()>> CodeCompletionHandler) {
-  if (getLangOpts().CPlusPlus11 && (AttrReqs & AR_CXX11AttributesParsed) &&
+  if (standardAttributesAllowed() && (AttrReqs & AR_CXX11AttributesParsed) &&
       isCXX11AttributeSpecifier()) {
     ParsedAttributesWithRange attrs(AttrFactory);
     ParseCXX11Attributes(attrs);

   SmallVector<SourceRange, 2> DynamicExceptionRanges;
   ExprResult NoexceptExpr;
   CachedTokens *ExceptionSpecTokens = nullptr;
-  ParsedAttributes FnAttrs(AttrFactory);
+  ParsedAttributesWithRange FnAttrs(AttrFactory);
   TypeResult TrailingReturnType;
 
   /* LocalEndLoc is the end location for the local FunctionTypeLoc.

     RParenLoc = Tracker.getCloseLocation();
     LocalEndLoc = RParenLoc;
     EndLoc = RParenLoc;
+
+    // If there are attributes following the identifier list, parse them and 
+    // prohibit them.
+    MaybeParseCXX11Attributes(FnAttrs);
+    ProhibitAttributes(FnAttrs);
   } else {
     if (Tok.isNot(tok::r_paren))
       ParseParameterDeclarationClause(D, FirstArgAttrs, ParamInfo, 

         TrailingReturnType = ParseTrailingReturnType(Range);
         EndLoc = Range.getEnd();
       }
+    } else if (standardAttributesAllowed()) {
+      MaybeParseCXX11Attributes(FnAttrs);
     }
   }
 

lib/Parse/ParseDeclCXX.cpp

 }
 
 static bool IsBuiltInOrStandardCXX11Attribute(IdentifierInfo *AttrName,
-                                               IdentifierInfo *ScopeName) {
   switch (AttributeList::getKind(AttrName, ScopeName,
                                  AttributeList::AS_CXX11)) {
   case AttributeList::AT_CarriesDependency:

                                      SourceLocation ScopeLoc) {
   assert(Tok.is(tok::l_paren) && "Not a C++11 attribute argument list");
   SourceLocation LParenLoc = Tok.getLocation();
+  AttributeList::Syntax Syntax = getLangOpts().CPlusPlus11
+                                     ? AttributeList::AS_CXX11
+                                     : AttributeList::AS_C2x;
 
   // If the attribute isn't known, we will not attempt to parse any
   // arguments.
-  if (!hasAttribute(AttrSyntax::CXX, ScopeName, AttrName,
-                    getTargetInfo(), getLangOpts())) {
+  if (!hasAttribute(getLangOpts().CPlusPlus11 ? AttrSyntax::CXX
+                                              : AttrSyntax::C,
+                    ScopeName, AttrName, getTargetInfo(), getLangOpts())) {
     // Eat the left paren, then skip to the ending right paren.
     ConsumeParen();
     SkipUntil(tok::r_paren);

     // GNU-scoped attributes have some special cases to handle GNU-specific
     // behaviors.
     ParseGNUAttributeArgs(AttrName, AttrNameLoc, Attrs, EndLoc, ScopeName,
-                          ScopeLoc, AttributeList::AS_CXX11, nullptr);
+                          ScopeLoc, Syntax, nullptr);
     return true;
   }
 

   if (ScopeName && ScopeName->getName() == "clang")
     NumArgs =
         ParseClangAttributeArgs(AttrName, AttrNameLoc, Attrs, EndLoc, ScopeName,
-                                ScopeLoc, AttributeList::AS_CXX11);
+                                ScopeLoc, Syntax);
   else
     NumArgs =
         ParseAttributeArgsCommon(AttrName, AttrNameLoc, Attrs, EndLoc,
-                                 ScopeName, ScopeLoc, AttributeList::AS_CXX11);
+                                 ScopeName, ScopeLoc, Syntax);
 
   const AttributeList *Attr = Attrs.getList();
   if (Attr && IsBuiltInOrStandardCXX11Attribute(AttrName, ScopeName)) {

   return true;
 }
 
-/// ParseCXX11AttributeSpecifier - Parse a C++11 attribute-specifier.
+/// ParseCXX11Attributespecifier - Parse a C++11 or C2x attribute-specifier.
 ///
 /// [C++11] attribute-specifier:
 ///         '[' '[' attribute-list ']' ']'

 ///         identifier
 void Parser::ParseCXX11AttributeSpecifier(ParsedAttributes &attrs,
                                           SourceLocation *endLoc) {
-  if (Tok.is(tok::kw_alignas)) {
+  bool CXXAttr = getLangOpts().CPlusPlus11;
+  if (CXXAttr && Tok.is(tok::kw_alignas)) {
     Diag(Tok.getLocation(), diag::warn_cxx98_compat_alignas);
     ParseAlignmentSpecifier(attrs, endLoc);
     return;
   }
 
-  assert(Tok.is(tok::l_square) && NextToken().is(tok::l_square)
-      && "Not a C++11 attribute list");
+  assert(Tok.is(tok::l_square) && NextToken().is(tok::l_square) &&
+         "Not a standards-based attribute list");
 
   Diag(Tok.getLocation(), diag::warn_cxx98_compat_attribute);
 

 
   SourceLocation CommonScopeLoc;
   IdentifierInfo *CommonScopeName = nullptr;
-  if (Tok.is(tok::kw_using)) {
+  if (CXXAttr && Tok.is(tok::kw_using)) {
     Diag(Tok.getLocation(), getLangOpts().CPlusPlus1z
                                 ? diag::warn_cxx14_compat_using_attribute_ns
                                 : diag::ext_using_attribute_ns);

                                            ScopeName, ScopeLoc);
 
     if (!AttrParsed)
-      attrs.addNew(AttrName,
-                   SourceRange(ScopeLoc.isValid() ? ScopeLoc : AttrLoc,
-                               AttrLoc),
-                   ScopeName, ScopeLoc, nullptr, 0, AttributeList::AS_CXX11);
+      attrs.addNew(
+          AttrName,
+          SourceRange(ScopeLoc.isValid() ? ScopeLoc : AttrLoc, AttrLoc),
+          ScopeName, ScopeLoc, nullptr, 0,
+          CXXAttr ? AttributeList::AS_CXX11 : AttributeList::AS_C2x);
 
     if (TryConsumeToken(tok::ellipsis))
       Diag(Tok, diag::err_cxx11_attribute_forbids_ellipsis)

     SkipUntil(tok::r_square);
 }
 
-/// ParseCXX11Attributes - Parse a C++11 attribute-specifier-seq.
+/// ParseCXX11Attributes - Parse a C++11 or C2x attribute-specifier-seq.
 ///
 /// attribute-specifier-seq:
 ///       attribute-specifier-seq[opt] attribute-specifier
 void Parser::ParseCXX11Attributes(ParsedAttributesWithRange &attrs,
                                   SourceLocation *endLoc) {
-  assert(getLangOpts().CPlusPlus11);
+  assert(standardAttributesAllowed());
 
   SourceLocation StartLoc = Tok.getLocation(), Loc;
   if (!endLoc)

lib/Parse/ParseTentative.cpp

 Parser::CXX11AttributeKind
 Parser::isCXX11AttributeSpecifier(bool Disambiguate,
                                   bool OuterMightBeMessageSend) {
-  if (Tok.is(tok::kw_alignas))
+  if (Tok.is(tok::kw_alignas) && getLangOpts().CPlusPlus11)
     return CAK_AttributeSpecifier;
 
   if (Tok.isNot(tok::l_square) || NextToken().isNot(tok::l_square))

lib/Sema/AttributeList.cpp

   // Normalize the attribute name, __foo__ becomes foo. This is only allowable
   // for GNU attributes.
   bool IsGNU = SyntaxUsed == AttributeList::AS_GNU ||
-               (SyntaxUsed == AttributeList::AS_CXX11 && ScopeName == "gnu");
+               ((SyntaxUsed == AttributeList::AS_CXX11 ||
+                SyntaxUsed == AttributeList::AS_C2x) && ScopeName == "gnu");
   if (IsGNU && AttrName.size() >= 4 && AttrName.startswith("__") &&
       AttrName.endswith("__"))
     AttrName = AttrName.slice(2, AttrName.size() - 2);

 
   // Ensure that in the case of C++11 attributes, we look for '::foo' if it is
   // unscoped.
-  if (ScopeName || SyntaxUsed == AS_CXX11)
+  if (ScopeName || SyntaxUsed == AS_CXX11 || SyntaxUsed == AS_C2x)
     FullName += "::";
   FullName += AttrName;
 

test/CXX/dcl.dcl/dcl.attr/dcl.align/p6.cpp

 alignas(4) extern int n9; // expected-note {{declared with 'alignas' attribute here}}
 
 
-enum alignas(2) E : char; // expected-note {{declared with 'alignas' attribute here}}
-enum E : char {}; // expected-error {{'alignas' must be specified on definition if it is specified on any declaration}}
+enum alignas(2) E : char; // expected-error {{an attribute list cannot appear here}}
+enum E : char {};
 
-enum alignas(4) F : char; // expected-note {{previous declaration is here}}
-enum alignas(2) F : char; // expected-error {{redeclaration has different alignment requirement (2 vs 4)}}
+enum alignas(4) F : char; // expected-error {{an attribute list cannot appear here}}
+enum alignas(2) F : char; // expected-error {{an attribute list cannot appear here}}
 
 enum G : char;
 enum alignas(8) G : char {};
 enum G : char;
 
-enum H : char {}; // expected-error {{'alignas' must be specified on definition if it is specified on any declaration}}
-enum alignas(1) H : char; // expected-note {{declared with 'alignas' attribute here}}
+enum H : char {};
+enum alignas(1) H : char; // expected-error {{an attribute list cannot appear here}}
 
 
 struct S;

 char *x1248 = X<1,2,4,8>::Buffer; // expected-note {{in instantiation of}}
 
 template<int M, int N, int O, int P> struct Y {
-  enum alignas(M) alignas(N) E : char;
+  enum alignas(M) alignas(N) E : char; // expected-error {{an attribute list cannot appear here}}
 };
 template<int M, int N, int O, int P>
 enum alignas(O) alignas(P) Y<M,N,O,P>::E : char { e };

test/Misc/ast-dump-c-attr.c

+// RUN: %clang_cc1 -triple x86_64-pc-linux -fc-attributes -Wno-deprecated-declarations -ast-dump -ast-dump-filter Test %s | FileCheck --strict-whitespace %s
+
+int Test1 [[deprecated]];
+// CHECK:      VarDecl{{.*}}Test1
+// CHECK-NEXT:   DeprecatedAttr 0x{{[^ ]*}} <col:13> "" ""
+
+enum [[deprecated("Frobble")]] Test2 {
+  Test3 [[deprecated]]
+};
+// CHECK:      EnumDecl{{.*}}Test2
+// CHECK-NEXT:   DeprecatedAttr 0x{{[^ ]*}} <col:8, col:28> "Frobble" ""
+// CHECK-NEXT:   EnumConstantDecl{{.*}}Test3
+// CHECK-NEXT:     DeprecatedAttr 0x{{[^ ]*}} <col:11> "" ""
+
+struct [[deprecated]] Test4 {
+  [[deprecated("Frobble")]] int Test5, Test6;
+  int Test7 [[deprecated]] : 12;
+};
+// CHECK:      RecordDecl{{.*}}Test4
+// CHECK-NEXT:   DeprecatedAttr 0x{{[^ ]*}} <col:10> "" ""
+// CHECK-NEXT:   FieldDecl{{.*}}Test5
+// CHECK-NEXT:     DeprecatedAttr 0x{{[^ ]*}} <col:5, col:25> "Frobble" ""
+// CHECK-NEXT:   FieldDecl{{.*}}Test6
+// CHECK-NEXT:     DeprecatedAttr 0x{{[^ ]*}} <col:5, col:25> "Frobble" ""
+// CHECK-NEXT:   FieldDecl{{.*}}Test7
+// CHECK-NEXT:     IntegerLiteral{{.*}}'int' 12
+// CHECK-NEXT:     DeprecatedAttr 0x{{[^ ]*}} <col:15> "" ""
+
+struct [[deprecated]] Test8;
+// CHECK:      RecordDecl{{.*}}Test8
+// CHECK-NEXT:   DeprecatedAttr 0x{{[^ ]*}} <col:10> "" ""
+
+[[deprecated]] void Test9(int Test10 [[deprecated]]);
+// CHECK:      FunctionDecl{{.*}}Test9
+// CHECK-NEXT:   ParmVarDecl{{.*}}Test10
+// CHECK-NEXT:     DeprecatedAttr 0x{{[^ ]*}} <col:40> "" ""
+// CHECK-NEXT:   DeprecatedAttr 0x{{[^ ]*}} <col:3> "" ""
+
+void Test11 [[deprecated]](void);
+// CHECK:      FunctionDecl{{.*}}Test11
+// CHECK-NEXT:   DeprecatedAttr 0x{{[^ ]*}} <col:15> "" ""
+
+void Test12(void) [[deprecated]] {}
+// CHECK:      FunctionDecl{{.*}}Test12
+// CHECK-NEXT:   CompoundStmt
+// CHECK-NEXT:   DeprecatedAttr 0x{{[^ ]*}} <col:21> "" ""

test/Parser/c2x-attributes.c

+// RUN: %clang_cc1 -fsyntax-only -fc-attributes -verify %s
+
+enum [[]] E {
+  One [[]],
+  Two,
+  Three [[]]
+};
+
+enum [[]] { Four };
+[[]] enum E2 { Five }; // expected-error {{an attribute list cannot appear here}}
+
+// FIXME: this diagnostic can be improved.
+enum { [[]] Six }; // expected-error {{expected identifier}}
+
+// FIXME: this diagnostic can be improved.
+enum E3 [[]] { Seven }; // expected-error {{expected identifier or '('}}
+
+struct [[]] S1 {
+  int i [[]];
+  int [[]] j;
+  int k[10] [[]];
+  int l[[]][10];
+  [[]] int m, n;
+  int o [[]] : 12;
+};
+
+[[]] struct S2 { int a; }; // expected-error {{an attribute list cannot appear here}}
+struct S3 [[]] { int a; }; // expected-error {{an attribute list cannot appear here}}
+
+union [[]] U {
+  double d [[]];
+  [[]] int i;
+};
+
+[[]] union U2 { double d; }; // expected-error {{an attribute list cannot appear here}}
+union U3 [[]] { double d; }; // expected-error {{an attribute list cannot appear here}}
+
+struct [[]] IncompleteStruct;
+union [[]] IncompleteUnion;
+enum [[]] IncompleteEnum; // expected-error {{an attribute list cannot appear here}}
+
+[[]] void f1(void);
+void [[]] f2(void);
+void f3 [[]] (void);
+void f4(void) [[]];
+
+void f5(int i [[]], [[]] int j, int [[]] k);
+
+void f6(a, b) [[]] int a; int b; { // expected-error {{an attribute list cannot appear here}}
+}
+
+// FIXME: technically, an attribute list cannot appear here, but we currently
+// parse it as part of the return type of the function, which is reasonable
+// behavior given that we *don't* want to parse it as part of the K&R parameter
+// declarations. It is disallowed to avoid a parsing ambiguity we already
+// handle well.
+int (*f7(a, b))(int, int) [[]] int a; int b; {
+  return 0;
+}
+
+[[]] int a, b;
+int c [[]], d [[]];
+
+void f8(void) [[]] {
+  [[]] int i, j;
+  int k, l [[]];
+}
+
+[[]] void f9(void) {
+  int i[10] [[]];
+  int (*fp1)(void)[[]];
+  int (*fp2 [[]])(void);
+
+  int * [[]] *ipp;
+}
+
+void f10(int j[static 10] [[]], int k[*] [[]]);
+
+void f11(void) {
+  [[]] {}
+  [[]] if (1) {}
+
+  [[]] switch (1) {
+  [[]] case 1: [[]] break;
+  [[]] default: break;
+  }
+
+  goto foo;
+  [[]] foo: (void)1;
+
+  [[]] for (;;);
+  [[]] while (1);
+  [[]] do [[]] { } while(1);
+
+  [[]] (void)1;
+
+  [[]];
+
+  (void)sizeof(int [4][[]]);
+  (void)sizeof(struct [[]] S3 { int a [[]]; });
+
+  [[]] return;
+}
+
+[[attr]] void f12(void); // expected-warning {{unknown attribute 'attr' ignored}}
+[[vendor::attr]] void f13(void); // expected-warning {{unknown attribute 'attr' ignored}}
+
+// Ensure that asm statements properly handle double colons.
+void test_asm(void) {
+  asm("ret" :::);
+  asm("foo" :: "r" (xx)); // expected-error {{use of undeclared identifier 'xx'}}
+}

test/Parser/cxx0x-attributes.cpp

 template <> struct [[]] Template<void>;
 
 enum [[]] E1 {};
-enum [[]] E2; // expected-error {{forbids forward references}}
-enum [[]] E1;
-enum [[]] E3 : int;
+enum [[]] E2; // expected-error {{forbids forward references}} // expected-error {{an attribute list cannot appear here}}
+enum [[]] E1; // expected-error {{an attribute list cannot appear here}}
+enum [[]] E3 : int; // expected-error {{an attribute list cannot appear here}}
 enum [[]] {
   k_123 [[]] = 123 // expected-warning {{attributes on an enumerator declaration are incompatible with C++ standards before C++17}}
 };
 enum [[]] E1 e; // expected-error {{an attribute list cannot appear here}}
 enum [[]] class E4 { }; // expected-error {{an attribute list cannot appear here}}
-enum struct [[]] E5;
+enum struct [[]] E5; // expected-error {{an attribute list cannot appear here}}
 
 struct S {
   friend int f [[]] (); // expected-FIXME{{an attribute list cannot appear here}}

test/Sema/attr-deprecated-c2x.c

+// RUN: %clang_cc1 %s -verify -fsyntax-only -fc-attributes
+
+int f() [[deprecated]]; // expected-note 2 {{'f' has been explicitly marked deprecated here}}
+void g() [[deprecated]];// expected-note {{'g' has been explicitly marked deprecated here}}
+void g();
+
+extern int var [[deprecated]]; // expected-note 2 {{'var' has been explicitly marked deprecated here}}
+
+int a() {
+  int (*ptr)() = f; // expected-warning {{'f' is deprecated}}
+  f(); // expected-warning {{'f' is deprecated}}
+
+  // test if attributes propagate to functions
+  g(); // expected-warning {{'g' is deprecated}}
+
+  return var; // expected-warning {{'var' is deprecated}}
+}
+
+// test if attributes propagate to variables
+extern int var;
+int w() {
+  return var; // expected-warning {{'var' is deprecated}}
+}
+
+int old_fn() [[deprecated]];// expected-note {{'old_fn' has been explicitly marked deprecated here}}
+int old_fn();
+int (*fn_ptr)() = old_fn; // expected-warning {{'old_fn' is deprecated}}
+
+int old_fn() {
+  return old_fn()+1;  // no warning, deprecated functions can use deprecated symbols.
+}
+
+struct foo {
+  int x [[deprecated]]; // expected-note 3 {{'x' has been explicitly marked deprecated here}}
+};
+
+void test1(struct foo *F) {
+  ++F->x;  // expected-warning {{'x' is deprecated}}
+  struct foo f1 = { .x = 17 }; // expected-warning {{'x' is deprecated}}
+  struct foo f2 = { 17 }; // expected-warning {{'x' is deprecated}}
+}
+
+typedef struct foo foo_dep [[deprecated]]; // expected-note {{'foo_dep' has been explicitly marked deprecated here}}
+foo_dep *test2;    // expected-warning {{'foo_dep' is deprecated}}
+
+struct [[deprecated, // expected-note {{'bar_dep' has been explicitly marked deprecated here}}
+         invalid_attribute]] bar_dep ;  // expected-warning {{unknown attribute 'invalid_attribute' ignored}}
+
+struct bar_dep *test3;   // expected-warning {{'bar_dep' is deprecated}}
+
+[[deprecated("this is the message")]] int i; // expected-note {{'i' has been explicitly marked deprecated here}}
+void test4(void) {
+  i = 12; // expected-warning {{'i' is deprecated: this is the message}}
+}

utils/TableGen/ClangAttrEmitter.cpp

 
     assert(V != "GCC" && "Given a GCC spelling, which means this hasn't been"
            "flattened!");
-    if (V == "CXX11" || V == "Pragma")
+    if (V == "CXX11" || V == "C2x" || V == "Pragma")
       NS = Spelling.getValueAsString("Namespace");
     bool Unset;
     K = Spelling.getValueAsBitOrUnset("KnownToGCC", Unset);

     if (Variety == "GNU") {
       Prefix = " __attribute__((";
       Suffix = "))";
-    } else if (Variety == "CXX11") {
+    } else if (Variety == "CXX11" || Variety == "C2x") {
       Prefix = " [[";
       Suffix = "]]";
       std::string Namespace = Spellings[I].nameSpace();

       // If this is the C++11 variety, also add in the LangOpts test.
       if (Variety == "CXX11")
         Test += " && LangOpts.CPlusPlus11";
+      else if (Variety == "C2x")
+        Test += " && LangOpts.CAttributes";
     } else if (Variety == "CXX11")
       // C++11 mode should be checked against LangOpts, which is presumed to be
       // present in the caller.
       Test = "LangOpts.CPlusPlus11";
+    else if (Variety == "C2x")
+      Test = "LangOpts.CAttributes";
 
     std::string TestStr =
         !Test.empty() ? Test + " ? " + llvm::itostr(Version) + " : 0" : "1";

   // and declspecs. Then generate a big switch statement for each of them.
   std::vector<Record *> Attrs = Records.getAllDerivedDefinitions("Attr");
   std::vector<Record *> Declspec, Microsoft, GNU, Pragma;
-  std::map<std::string, std::vector<Record *>> CXX;
+  std::map<std::string, std::vector<Record *>> CXX, C2x;
 
   // Walk over the list of all attributes, and split them out based on the
   // spelling variety.

         Microsoft.push_back(R);
       else if (Variety == "CXX11")
         CXX[SI.nameSpace()].push_back(R);
+      else if (Variety == "C2x")
+        C2x[SI.nameSpace()].push_back(R);
       else if (Variety == "Pragma")
         Pragma.push_back(R);
     }

   OS << "case AttrSyntax::Pragma:\n";
   OS << "  return llvm::StringSwitch<int>(Name)\n";
   GenerateHasAttrSpellingStringSwitch(Pragma, OS, "Pragma");
-  OS << "case AttrSyntax::CXX: {\n";
-  // C++11-style attributes are further split out based on the Scope.
-  for (auto I = CXX.cbegin(), E = CXX.cend(); I != E; ++I) {
-    if (I != CXX.begin())
-      OS << " else ";
-    if (I->first.empty())
-      OS << "if (!Scope || Scope->getName() == \"\") {\n";
-    else
-      OS << "if (Scope->getName() == \"" << I->first << "\") {\n";
-    OS << "  return llvm::StringSwitch<int>(Name)\n";
-    GenerateHasAttrSpellingStringSwitch(I->second, OS, "CXX11", I->first);
-    OS << "}";
-  }
-  OS << "\n}\n";
+  auto fn = [&OS](const char *Spelling, const char *Variety,
+                  const std::map<std::string, std::vector<Record *>> &List) {
+    OS << "case AttrSyntax::" << Variety << ": {\n";
+    // C++11-style attributes are further split out based on the Scope.
+    for (auto I = List.cbegin(), E = List.cend(); I != E; ++I) {
+      if (I != List.cbegin())
+        OS << " else ";
+      if (I->first.empty())
+        OS << "if (!Scope || Scope->getName() == \"\") {\n";
+      else
+        OS << "if (Scope->getName() == \"" << I->first << "\") {\n";
+      OS << "  return llvm::StringSwitch<int>(Name)\n";
+      GenerateHasAttrSpellingStringSwitch(I->second, OS, Spelling, I->first);
+      OS << "}";
+    }
+    OS << "\n}\n";
+  };
+  fn("CXX11", "CXX", CXX);
+  fn("C2x", "C", C2x);
   OS << "}\n";
 }
 

          << StringSwitch<unsigned>(Spellings[I].variety())
                 .Case("GNU", 0)
                 .Case("CXX11", 1)
-                .Case("Declspec", 2)
-                .Case("Microsoft", 3)
-                .Case("Keyword", 4)
-                .Case("Pragma", 5)
+                .Case("C2x", 2)
+                .Case("Declspec", 3)
+                .Case("Microsoft", 4)
+                .Case("Keyword", 5)
+                .Case("Pragma", 6)
                 .Default(0)
          << " && Scope == \"" << Spellings[I].nameSpace() << "\")\n"
          << "        return " << I << ";\n";

 
   std::vector<Record *> Attrs = Records.getAllDerivedDefinitions("Attr");
   std::vector<StringMatcher::StringPair> GNU, Declspec, Microsoft, CXX11,
-      Keywords, Pragma;
+      Keywords, Pragma, C2x;
   std::set<std::string> Seen;
   for (const auto *A : Attrs) {
     const Record &Attr = *A;

           Matches = &CXX11;
           Spelling += S.nameSpace();
           Spelling += "::";
+        } else if (Variety == "C2x") {
+          Matches = &C2x;
+          Spelling += S.nameSpace();
+          Spelling += "::";
         } else if (Variety == "GNU")
           Matches = &GNU;
         else if (Variety == "Declspec")

   StringMatcher("Name", Microsoft, OS).Emit();
   OS << "  } else if (AttributeList::AS_CXX11 == Syntax) {\n";
   StringMatcher("Name", CXX11, OS).Emit();
+  OS << "  } else if (AttributeList::AS_C2x == Syntax) {\n";
+  StringMatcher("Name", C2x, OS).Emit();
   OS << "  } else if (AttributeList::AS_Keyword == Syntax || ";
   OS << "AttributeList::AS_ContextSensitiveKeyword == Syntax) {\n";
   StringMatcher("Name", Keywords, OS).Emit();

 enum SpellingKind {
   GNU = 1 << 0,
   CXX11 = 1 << 1,
-  Declspec = 1 << 2,
-  Microsoft = 1 << 3,
-  Keyword = 1 << 4,
-  Pragma = 1 << 5
+  C2x = 1 << 2,
+  Declspec = 1 << 3,
+  Microsoft = 1 << 4,
+  Keyword = 1 << 5,
+  Pragma = 1 << 6
 };
 
 static void WriteDocumentation(RecordKeeper &Records,

     SpellingKind Kind = StringSwitch<SpellingKind>(I.variety())
                             .Case("GNU", GNU)
                             .Case("CXX11", CXX11)
+                            .Case("C2x", C2x)
                             .Case("Declspec", Declspec)
                             .Case("Microsoft", Microsoft)
                             .Case("Keyword", Keyword)

     SupportedSpellings |= Kind;
 
     std::string Name;
-    if (Kind == CXX11 && !I.nameSpace().empty())
+    if ((Kind == CXX11 || Kind == C2x) && !I.nameSpace().empty())
       Name = I.nameSpace() + "::";
     Name += I.name();
 

 
   // List what spelling syntaxes the attribute supports.
   OS << ".. csv-table:: Supported Syntaxes\n";
-  OS << "   :header: \"GNU\", \"C++11\", \"__declspec\", \"Keyword\",";
+  OS << "   :header: \"GNU\", \"C++11\", \"C2x\", \"__declspec\", \"Keyword\",";
   OS << " \"Pragma\", \"Pragma clang attribute\"\n\n";
   OS << "   \"";
   if (SupportedSpellings & GNU) OS << "X";

   OS << "\",\"";
   if (SupportedSpellings & CXX11) OS << "X";
   OS << "\",\"";
+  if (SupportedSpellings & C2x) OS << "X";
+  OS << "\",\"";
   if (SupportedSpellings & Declspec) OS << "X";
   OS << "\",\"";
   if (SupportedSpellings & Keyword) OS << "X";