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 ↗

(On Diff #113747)

Missing underscore between "fc" and "attributes".

lib/Parse/ParseDecl.cpp

1512 ↗

(On Diff #113747)

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 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

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

3947 ↗

(On Diff #114447)

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

3956 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

Ah, good to know. I'll remove.

3956 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

It's kind of long, but how about DoubleSquareBracketAttributes

include/clang/Driver/Options.td

607 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

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

include/clang/Driver/Options.td

607 ↗

(On Diff #114447)

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

lib/Parse/ParseDecl.cpp

4219 ↗

(On Diff #114447)

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 ↗

(On Diff #114447)

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

This is not formatted how we normally format tablegen files.

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

4422

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

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

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

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

4422

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

Correct, I've simplified.

../llvm/tools/clang/include/clang/Basic/Attr.td

 class GNU<string name> : Spelling<name, "GNU">;
 class Declspec<string name> : Spelling<name, "Declspec">;
 class Microsoft<string name> : Spelling<name, "Microsoft">;
 class CXX11<string namespace, string name, int version = 1>
     : Spelling<name, "CXX11"> {
   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;
 }
 
 // The GCC spelling implies GNU<name, "GNU"> and CXX11<"gnu", name> and also
 // sets KnownToGCC to 1. This spelling should be used for any GCC-compatible
 // attributes.

   let Spellings = [GNU<"kernel">];
   let Subjects = SubjectList<[Function]>;
   let Documentation = [RenderScriptKernelAttributeDocs];
   let LangOpts = [RenderScript];
 }
 
 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.
               StringArgument<"Replacement", 1>];
   let MeaningfulToClassTemplateDefinition = 1;
   let Documentation = [DeprecatedDocs];
 }
 

../llvm/tools/clang/include/clang/Basic/Attributes.h

enum class AttrSyntax {
   /// Is the identifier known as a GNU-style attribute?
   GNU,
   /// Is the identifier known as a __declspec-style attribute?
   Declspec,
   /// Is the identifier known as a [] Microsoft-style attribute?
   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
 };
 
 /// \brief Return the version number associated with the attribute if we
 /// recognize and implement the attribute specified by the given information.
 int hasAttribute(AttrSyntax Syntax, const IdentifierInfo *Scope,
                  const IdentifierInfo *Attr, const TargetInfo &Target,
                  const LangOptions &LangOpts);
 
 } // end namespace clang
 
 #endif // LLVM_CLANG_BASIC_ATTRIBUTES_H

../llvm/tools/clang/include/clang/Basic/LangOptions.def

 LANGOPT(MSBitfields       , 1, 0, "Microsoft-compatible structure layout")
 LANGOPT(Freestanding, 1, 0, "freestanding implementation")
 LANGOPT(NoBuiltin         , 1, 0, "disable builtin functions")
 LANGOPT(NoMathBuiltin     , 1, 0, "disable math builtin functions")
 LANGOPT(GNUAsm            , 1, 1, "GNU-style inline assembly")
 LANGOPT(CoroutinesTS      , 1, 0, "C++ coroutines TS")
 LANGOPT(RelaxedTemplateTemplateArgs, 1, 0, "C++17 relaxed matching of template template arguments")
 
+LANGOPT(DoubleSquareBracketAttributes, 1, 0, "'[[]]' attributes extension for all language standard modes")
+
 BENIGN_LANGOPT(ThreadsafeStatics , 1, 1, "thread-safe static initializers")
 LANGOPT(POSIXThreads      , 1, 0, "POSIX thread support")
 LANGOPT(Blocks            , 1, 0, "blocks extension to C")
 BENIGN_LANGOPT(EmitAllDecls      , 1, 0, "emitting all declarations")
 LANGOPT(MathErrno         , 1, 1, "errno in math functions")
 BENIGN_LANGOPT(HeinousExtensions , 1, 0, "extensions that we really don't like and may be ripped out at any time")
 LANGOPT(Modules           , 1, 0, "modules extension to C")
 COMPATIBLE_LANGOPT(ModulesTS  , 1, 0, "C++ Modules TS")

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

 def fno_asm_blocks : Flag<["-"], "fno-asm-blocks">, Group<f_Group>;
 
 def fassume_sane_operator_new : Flag<["-"], "fassume-sane-operator-new">, Group<f_Group>;
 def fastcp : Flag<["-"], "fastcp">, Group<f_Group>;
 def fastf : Flag<["-"], "fastf">, Group<f_Group>;
 def fast : Flag<["-"], "fast">, Group<f_Group>;
 def fasynchronous_unwind_tables : Flag<["-"], "fasynchronous-unwind-tables">, Group<f_Group>;
 
+def fdouble_square_bracket_attributes
+    : Flag<[ "-" ], "fdouble-square-bracket-attributes">,
+      Group<f_Group>, Flags<[ DriverOption, CC1Option ]>,
+      HelpText<"Enable '[[]]' attributes in all C and C++ language modes">;
+def fno_double_square_bracket_attributes
+    : Flag<[ "-" ], "fno-fdouble-square-bracket-attributes">,
+      Group<f_Group>, Flags<[ DriverOption ]>,
+      HelpText<"Disable '[[]]' attributes in all C and C++ language modes">;
+
 def fautolink : Flag <["-"], "fautolink">, Group<f_Group>;
 def fno_autolink : Flag <["-"], "fno-autolink">, Group<f_Group>,
   Flags<[DriverOption, CC1Option]>,
   HelpText<"Disable generation of linker directives for automatic library linking">;
 
 // C++ Coroutines TS
 def fcoroutines_ts : Flag <["-"], "fcoroutines-ts">, Group<f_Group>,
   Flags<[DriverOption, CC1Option]>,

../llvm/tools/clang/include/clang/Parse/Parser.h

                              = Declarator::TypeNameContext,
                            AccessSpecifier AS = AS_none,
                            Decl **OwnedType = nullptr,
                            ParsedAttributes *Attrs = nullptr);
 
 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 [[]] attributes enabled?
+  bool standardAttributesAllowed() const {
+    const LangOptions &LO = getLangOpts();
+    return LO.DoubleSquareBracketAttributes;
+  }
+
+  // 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))
       return;
     DiagnoseMisplacedCXX11Attribute(Attrs, CorrectLocation);
   }
   void DiagnoseMisplacedCXX11Attribute(ParsedAttributesWithRange &Attrs,
                                        SourceLocation CorrectLocation);
 
   void stripTypeAttributesOffDeclSpec(ParsedAttributesWithRange &Attrs,
                                       DeclSpec &DS, Sema::TagUseKind TUK);
 
   void ProhibitAttributes(ParsedAttributesWithRange &attrs) {
     if (!attrs.Range.isValid()) return;
     DiagnoseProhibitedAttributes(attrs);
     attrs.clear();
   }
   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();
 
   /// \brief Parses syntax-generic attribute arguments for attributes which are
   /// known to the implementation, and adds them to the given ParsedAttributes
   /// list with the given attribute syntax. Returns the number of arguments
   /// parsed for the attribute.
   unsigned

 
   unsigned
   ParseClangAttributeArgs(IdentifierInfo *AttrName, SourceLocation AttrNameLoc,
                           ParsedAttributes &Attrs, SourceLocation *EndLoc,
                           IdentifierInfo *ScopeName, SourceLocation ScopeLoc,
                           AttributeList::Syntax Syntax);
 
   void MaybeParseCXX11Attributes(Declarator &D) {
-    if (getLangOpts().CPlusPlus11 && isCXX11AttributeSpecifier()) {
+    if (standardAttributesAllowed() && isCXX11AttributeSpecifier()) {
       ParsedAttributesWithRange attrs(AttrFactory);
       SourceLocation endLoc;
       ParseCXX11Attributes(attrs, &endLoc);
       D.takeAttributes(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);
   }
 
   void ParseCXX11AttributeSpecifier(ParsedAttributes &attrs,
                                     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,
                                IdentifierInfo *ScopeName,
                                SourceLocation ScopeLoc);
 
   IdentifierInfo *TryParseCXX11AttributeIdentifier(SourceLocation &Loc);
 

../llvm/tools/clang/include/clang/Sema/AttributeList.h

 class AttributeList { // TODO: This should really be called ParsedAttribute
 public:
   /// The style used to specify an attribute.
   enum Syntax {
     /// __attribute__((...))
     AS_GNU,
     /// [[...]]
     AS_CXX11,
+    /// [[...]]
+    AS_C2x,
     /// __declspec(...)
     AS_Declspec,
     /// [uuid("...")] class Foo
     AS_Microsoft,
     /// __ptr16, alignas(...), etc.
     AS_Keyword,
     /// #pragma ...
     AS_Pragma,

     return getKind() == AT_Aligned && isKeywordAttribute();
   }
 
   bool isDeclspecAttribute() const { return SyntaxUsed == AS_Declspec; }
   bool isMicrosoftAttribute() const { return SyntaxUsed == AS_Microsoft; }
   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;
   }
 
   bool isContextSensitiveKeywordAttribute() const {
     return SyntaxUsed == AS_ContextSensitiveKeyword;
   }
 

../llvm/tools/clang/lib/Frontend/CompilerInvocation.cpp

   Opts.TraditionalCPP = Args.hasArg(OPT_traditional_cpp);
 
   Opts.RTTI = Opts.CPlusPlus && !Args.hasArg(OPT_fno_rtti);
   Opts.RTTIData = Opts.RTTI && !Args.hasArg(OPT_fno_rtti_data);
   Opts.Blocks = Args.hasArg(OPT_fblocks) || (Opts.OpenCL
     && Opts.OpenCLVersion >= 200);
   Opts.BlocksRuntimeOptional = Args.hasArg(OPT_fblocks_runtime_optional);
   Opts.CoroutinesTS = Args.hasArg(OPT_fcoroutines_ts);
+  
+  // Enable [[]] attributes in C++11 by default.
+  Opts.DoubleSquareBracketAttributes =
+      Args.hasFlag(OPT_fdouble_square_bracket_attributes,
+                   OPT_fno_double_square_bracket_attributes, Opts.CPlusPlus11);
+
   Opts.ModulesTS = Args.hasArg(OPT_fmodules_ts);
   Opts.Modules = Args.hasArg(OPT_fmodules) || Opts.ModulesTS;
   Opts.ModulesStrictDeclUse = Args.hasArg(OPT_fmodules_strict_decluse);
   Opts.ModulesDeclUse =
       Args.hasArg(OPT_fmodules_decluse) || Opts.ModulesStrictDeclUse;
   Opts.ModulesLocalVisibility =
       Args.hasArg(OPT_fmodules_local_submodule_visibility) || Opts.ModulesTS;
   Opts.ModulesCodegen = Args.hasArg(OPT_fmodules_codegen);

../llvm/tools/clang/lib/Lex/Lexer.cpp

       Kind = tok::pipe;
     }
     break;
   case ':':
     Char = getCharAndSize(CurPtr, SizeTmp);
     if (LangOpts.Digraphs && Char == '>') {
       Kind = tok::r_square; // ':>' -> ']'
       CurPtr = ConsumeChar(CurPtr, SizeTmp, Result);
-    } else if (LangOpts.CPlusPlus && Char == ':') {
+    } else if ((LangOpts.CPlusPlus ||
+                LangOpts.DoubleSquareBracketAttributes) &&
+               Char == ':') {
       Kind = tok::coloncolon;
       CurPtr = ConsumeChar(CurPtr, SizeTmp, Result);
     } else {
       Kind = tok::colon;
     }
     break;
   case ';':
     Kind = tok::semi;

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

 void Parser::DiagnoseProhibitedAttributes(ParsedAttributesWithRange &attrs) {
   Diag(attrs.Range.getBegin(), diag::err_attributes_not_allowed)
     << attrs.Range;
 }
 
 void Parser::ProhibitCXX11Attributes(ParsedAttributesWithRange &Attrs,
                                      unsigned DiagID) {
   for (AttributeList *Attr = Attrs.getList(); Attr; Attr = Attr->getNext()) {
-    if (!Attr->isCXX11Attribute())
+    if (!Attr->isCXX11Attribute() && !Attr->isC2xAttribute())
       continue;
     if (Attr->getKind() == AttributeList::UnknownAttribute)
       Diag(Attr->getLoc(), diag::warn_unknown_attribute_ignored)
           << Attr->getName();
     else {
       Diag(Attr->getLoc(), DiagID)
         << Attr->getName();
       Attr->setInvalid();

 
       // If this is not a declaration specifier token, we're done reading decl
       // specifiers.  First verify that DeclSpec's are consistent.
       DS.Finish(Actions, Policy);
       return;
 
     case tok::l_square:
     case tok::kw_alignas:
-      if (!getLangOpts().CPlusPlus11 || !isCXX11AttributeSpecifier())
+      if (!standardAttributesAllowed() || !isCXX11AttributeSpecifier())
         goto DoneWithDeclSpec;
 
       ProhibitAttributes(attrs);
       // FIXME: It would be good to recover by accepting the attributes,
       //        but attempting to do that now would cause serious
       //        madness in terms of diagnostics.
       attrs.clear();
       attrs.Range = SourceRange();

     AttrsLastTime = false;
   }
 }
 
 /// ParseStructDeclaration - Parse a struct declaration without the terminating
 /// 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:
 ///         struct-declarator
 ///         struct-declarator-list ',' struct-declarator
 /// [GNU]   struct-declarator-list ',' attributes[opt] struct-declarator
 ///       struct-declarator:
 ///         declarator
 /// [GNU]   declarator attributes[opt]
 ///         declarator[opt] ':' constant-expression
 /// [GNU]   declarator[opt] ':' constant-expression attributes[opt]
 ///
 void Parser::ParseStructDeclaration(
     ParsingDeclSpec &DS,
     llvm::function_ref<void(ParsingFieldDeclarator &)> FieldsCallback) {
 
   if (Tok.is(tok::kw___extension__)) {
     // __extension__ silences extension warnings in the subexpression.
     ExtensionRAIIObject O(Diags);  // Use RAII to do this.
     ConsumeToken();
     return ParseStructDeclaration(DS, FieldsCallback);
   }
 
+  // Parse leading attributes.
+  ParsedAttributesWithRange Attrs(AttrFactory);
+  MaybeParseCXX11Attributes(Attrs);
+  DS.takeAttributesFrom(Attrs);
+
   // Parse the common specifier-qualifiers-list piece.
   ParseSpecifierQualifierList(DS);
 
   // If there are no declarators, this is a free-standing declaration
   // specifier. Let the actions module cope with it.
   if (Tok.is(tok::semi)) {
     RecordDecl *AnonRecord = nullptr;
     Decl *TheDecl = Actions.ParsedFreeStandingDeclSpec(getCurScope(), AS_none,

     }
     IdentifierInfo *Ident = Tok.getIdentifierInfo();
     SourceLocation IdentLoc = ConsumeToken();
 
     // If attributes exist after the enumerator, parse them.
     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*/;
       ParseCXX11Attributes(attrs);
     }
 
     SourceLocation EqualLoc;
     ExprResult AssignedVal;
     EnumAvailabilityDiags.emplace_back(*this);

 /// [C++0x]    attribute-specifier[opt] is allowed before cv-qualifier-seq
 ///              [ only if AttReqs & AR_CXX11AttributesParsed ]
 /// Note: vendor can be GNU, MS, etc and can be explicitly controlled via
 /// AttrRequirements bitmask values.
 void Parser::ParseTypeQualifierListOpt(
     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);
     DS.takeAttributesFrom(attrs);
   }
 
   SourceLocation EndLoc;
 

   SourceLocation VolatileQualifierLoc;
   SourceLocation RestrictQualifierLoc;
   ExceptionSpecificationType ESpecType = EST_None;
   SourceRange ESpecRange;
   SmallVector<ParsedType, 2> DynamicExceptions;
   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.
      EndLoc is the end location for the function declarator.
      They differ for trailing return types. */
   SourceLocation StartLoc, LocalEndLoc, EndLoc;
   SourceLocation LParenLoc, RParenLoc;
   LParenLoc = Tracker.getOpenLocation();
   StartLoc = LParenLoc;
 
   if (isFunctionDeclaratorIdentifierList()) {
     if (RequiresArg)
       Diag(Tok, diag::err_argument_required_after_attribute);
 
     ParseFunctionDeclaratorIdentifierList(D, ParamInfo);
 
     Tracker.consumeClose();
     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, 
                                       EllipsisLoc);
     else if (RequiresArg)
       Diag(Tok, diag::err_argument_required_after_attribute);
 
     HasProto = ParamInfo.size() || getLangOpts().CPlusPlus;

         Diag(Tok, diag::warn_cxx98_compat_trailing_return_type);
         if (D.getDeclSpec().getTypeSpecType() == TST_auto)
           StartLoc = D.getDeclSpec().getTypeSpecTypeLoc();
         LocalEndLoc = Tok.getLocation();
         SourceRange Range;
         TrailingReturnType = ParseTrailingReturnType(Range);
         EndLoc = Range.getEnd();
       }
+    } else if (standardAttributesAllowed()) {
+      MaybeParseCXX11Attributes(FnAttrs);
     }
   }
 
   // Collect non-parameter declarations from the prototype if this is a function
   // declaration. They will be moved into the scope of the function. Only do
   // this in C and not C++, where the decls will continue to live in the
   // surrounding context.
   SmallVector<NamedDecl *, 0> DeclsInPrototype;

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

       Loc = ConsumeToken();
       return &PP.getIdentifierTable().get(Spelling);
     }
     return nullptr;
   }
 }
 
 static bool IsBuiltInOrStandardCXX11Attribute(IdentifierInfo *AttrName,
-                                               IdentifierInfo *ScopeName) {
   switch (AttributeList::getKind(AttrName, ScopeName,
                                  AttributeList::AS_CXX11)) {
   case AttributeList::AT_CarriesDependency:
   case AttributeList::AT_Deprecated:
   case AttributeList::AT_FallThrough:
   case AttributeList::AT_CXX11NoReturn:
     return true;
   case AttributeList::AT_WarnUnusedResult:

 bool Parser::ParseCXX11AttributeArgs(IdentifierInfo *AttrName,
                                      SourceLocation AttrNameLoc,
                                      ParsedAttributes &Attrs,
                                      SourceLocation *EndLoc,
                                      IdentifierInfo *ScopeName,
                                      SourceLocation ScopeLoc) {
   assert(Tok.is(tok::l_paren) && "Not a C++11 attribute argument list");
   SourceLocation LParenLoc = Tok.getLocation();
+  const LangOptions &LO = getLangOpts();
+  bool AsCXX =
+      LO.CPlusPlus11 || (LO.DoubleSquareBracketAttributes && LO.CPlusPlus);
+  AttributeList::Syntax Syntax =
+      AsCXX ? 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(AsCXX ? AttrSyntax::CXX : AttrSyntax::C, ScopeName,
+                    AttrName, getTargetInfo(), getLangOpts())) {
     // Eat the left paren, then skip to the ending right paren.
     ConsumeParen();
     SkipUntil(tok::r_paren);
     return false;
   }
 
   if (ScopeName && ScopeName->getName() == "gnu") {
     // 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;
   }
 
   unsigned NumArgs;
   // Some Clang-scoped attributes have some special parsing behavior.
   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)) {
     // If the attribute is a standard or built-in attribute and we are
     // parsing an argument list, we need to determine whether this attribute
     // was allowed to have an argument list (such as [[deprecated]]), and how
     // many arguments were parsed (so we can diagnose on [[deprecated()]]).
     if (Attr->getMaxArgs() && !NumArgs) {

           << AttrName
           << FixItHint::CreateRemoval(SourceRange(LParenLoc, *EndLoc));
       Attr->setInvalid(true);
     }
   }
   return true;
 }
 
-/// ParseCXX11AttributeSpecifier - Parse a C++11 attribute-specifier.
+/// ParseCXX11AttributeSpecifier - Parse a C++11 or C2x attribute-specifier.
 ///
 /// [C++11] attribute-specifier:
 ///         '[' '[' attribute-list ']' ']'
 ///         alignment-specifier
 ///
 /// [C++11] attribute-list:
 ///         attribute[opt]
 ///         attribute-list ',' attribute[opt]

 void Parser::ParseCXX11AttributeSpecifier(ParsedAttributes &attrs,
                                           SourceLocation *endLoc) {
   if (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 double square bracket attribute list");
 
   Diag(Tok.getLocation(), diag::warn_cxx98_compat_attribute);
 
   ConsumeBracket();
   ConsumeBracket();
 
   SourceLocation CommonScopeLoc;
   IdentifierInfo *CommonScopeName = nullptr;

           << AttrName << SourceRange(SeenAttrs[AttrName]);
 
     // Parse attribute arguments
     if (Tok.is(tok::l_paren))
       AttrParsed = ParseCXX11AttributeArgs(AttrName, AttrLoc, attrs, endLoc,
                                            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,
+          getLangOpts().CPlusPlus ? AttributeList::AS_CXX11
+                                  : AttributeList::AS_C2x);
 
     if (TryConsumeToken(tok::ellipsis))
       Diag(Tok, diag::err_cxx11_attribute_forbids_ellipsis)
         << AttrName->getName();
   }
 
   if (ExpectAndConsume(tok::r_square))
     SkipUntil(tok::r_square);
   if (endLoc)
     *endLoc = Tok.getLocation();
   if (ExpectAndConsume(tok::r_square))
     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)
     endLoc = &Loc;
 
   do {
     ParseCXX11AttributeSpecifier(attrs, endLoc);
   } while (isCXX11AttributeSpecifier());

../llvm/tools/clang/lib/Sema/AttributeList.cpp

 
 #include "clang/Sema/AttrParsedAttrKinds.inc"
 
 static StringRef normalizeAttrName(StringRef AttrName, StringRef ScopeName,
                                    AttributeList::Syntax SyntaxUsed) {
   // 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);
 
   return AttrName;
 }
 
 AttributeList::Kind AttributeList::getKind(const IdentifierInfo *Name,
                                            const IdentifierInfo *ScopeName,
                                            Syntax SyntaxUsed) {
   StringRef AttrName = Name->getName();
 
   SmallString<64> FullName;
   if (ScopeName)
     FullName += ScopeName->getName();
 
   AttrName = normalizeAttrName(AttrName, FullName, SyntaxUsed);
 
   // 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;
 
   return ::getAttrKind(FullName, SyntaxUsed);
 }
 
 unsigned AttributeList::getAttributeSpellingListIndex() const {
   // Both variables will be used in tablegen generated

../llvm/tools/clang/test/Misc/ast-dump-c-attr.c

+// RUN: %clang_cc1 -triple x86_64-pc-linux -fdouble-square-bracket-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> "" ""

../llvm/tools/clang/test/Parser/c2x-attributes.c

+// RUN: %clang_cc1 -fsyntax-only -fdouble-square-bracket-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;
+enum __attribute__((deprecated)) IncompleteEnum2;
+
+[[]] 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'}}
+}
+
+// Do not allow 'using' to introduce vendor attribute namespaces.
+[[using vendor: attr1, attr2]] void f14(void); // expected-error {{expected ']'}} \
+                                               // expected-warning {{unknown attribute 'vendor' ignored}} \
+                                               // expected-warning {{unknown attribute 'using' ignored}}
+
+struct [[]] S4 *s; // expected-error {{an attribute list cannot appear here}}
+struct S5 {};
+int c = sizeof(struct [[]] S5); // expected-error {{an attribute list cannot appear here}}

../llvm/tools/clang/test/Parser/c2x-attributes.m

+// RUN: %clang_cc1 -fsyntax-only -fdouble-square-bracket-attributes -verify %s
+// expected-no-diagnostics
+
+enum __attribute__((deprecated)) E1 : int; // ok
+enum [[deprecated]] E2 : int;
+
+@interface Base
+@end
+
+@interface S : Base
+- (void) bar;
+@end
+
+@interface T : Base
+- (S *) foo;
+@end
+
+
+void f(T *t) {
+  [[]][[t foo] bar];
+}

../llvm/tools/clang/test/Sema/attr-deprecated-c2x.c

+// RUN: %clang_cc1 %s -verify -fsyntax-only -fdouble-square-bracket-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}}
+}

../llvm/tools/clang/utils/TableGen/ClangAttrEmitter.cpp

                     const std::string &Namespace, bool KnownToGCC) :
     V(Variety), N(Name), NS(Namespace), K(KnownToGCC) {}
   explicit FlattenedSpelling(const Record &Spelling) :
     V(Spelling.getValueAsString("Variety")),
     N(Spelling.getValueAsString("Name")) {
 
     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);
   }
 
   const std::string &variety() const { return V; }
   const std::string &name() const { return N; }
   const std::string &nameSpace() const { return NS; }

     // of an attribute without considering prefix and suffix.
     llvm::SmallString<64> Spelling;
     std::string Name = Spellings[I].name();
     std::string Variety = Spellings[I].variety();
 
     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 (!Namespace.empty()) {
         Spelling += Namespace;
         Spelling += "::";
       }
     } else if (Variety == "Declspec") {

     if (Attr->isSubClassOf("TargetSpecificAttr")) {
       const Record *R = Attr->getValueAsDef("Target");
       std::vector<StringRef> Arches = R->getValueAsListOfStrings("Arches");
       GenerateTargetSpecificAttrChecks(R, Arches, Test, nullptr);
 
       // 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.DoubleSquareBracketAttributes";
     } 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.DoubleSquareBracketAttributes";
 
     std::string TestStr =
         !Test.empty() ? Test + " ? " + llvm::itostr(Version) + " : 0" : "1";
     std::vector<FlattenedSpelling> Spellings = GetFlattenedSpellings(*Attr);
     for (const auto &S : Spellings)
       if (Variety.empty() || (Variety == S.variety() &&
                               (Scope.empty() || Scope == S.nameSpace())))
         OS << "    .Case(\"" << S.name() << "\", " << TestStr << ")\n";
   }
   OS << "    .Default(0);\n";
 }
 
 // Emits the list of spellings for attributes.
 void EmitClangAttrHasAttrImpl(RecordKeeper &Records, raw_ostream &OS) {
   emitSourceFileHeader("Code to implement the __has_attribute logic", OS);
 
   // Separate all of the attributes out into four group: generic, C++11, GNU,
   // 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.
   for (auto *R : Attrs) {
     std::vector<FlattenedSpelling> Spellings = GetFlattenedSpellings(*R);
     for (const auto &SI : Spellings) {
       const std::string &Variety = SI.variety();
       if (Variety == "GNU")
         GNU.push_back(R);
       else if (Variety == "Declspec")
         Declspec.push_back(R);
       else if (Variety == "Microsoft")
         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 << "const llvm::Triple &T = Target.getTriple();\n";
   OS << "switch (Syntax) {\n";
   OS << "case AttrSyntax::GNU:\n";
   OS << "  return llvm::StringSwitch<int>(Name)\n";
   GenerateHasAttrSpellingStringSwitch(GNU, OS, "GNU");
   OS << "case AttrSyntax::Declspec:\n";
   OS << "  return llvm::StringSwitch<int>(Name)\n";
   GenerateHasAttrSpellingStringSwitch(Declspec, OS, "Declspec");
   OS << "case AttrSyntax::Microsoft:\n";
   OS << "  return llvm::StringSwitch<int>(Name)\n";
   GenerateHasAttrSpellingStringSwitch(Microsoft, OS, "Microsoft");
   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";
 }
 
 void EmitClangAttrSpellingListIndex(RecordKeeper &Records, raw_ostream &OS) {
   emitSourceFileHeader("Code to translate different attribute spellings "
                        "into internal identifiers", OS);
 
   OS << "  switch (AttrKind) {\n";
 
   ParsedAttrMap Attrs = getParsedAttrList(Records);
   for (const auto &I : Attrs) {
     const Record &R = *I.second;
     std::vector<FlattenedSpelling> Spellings = GetFlattenedSpellings(R);
     OS << "  case AT_" << I.first << ": {\n";
     for (unsigned I = 0; I < Spellings.size(); ++ I) {
       OS << "    if (Name == \"" << Spellings[I].name() << "\" && "
          << "SyntaxUsed == "
          << 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";
     }
 
     OS << "    break;\n";
     OS << "  }\n";
   }

 }
 
 // Emits the kind list of parsed attributes
 void EmitClangAttrParsedAttrKinds(RecordKeeper &Records, raw_ostream &OS) {
   emitSourceFileHeader("Attribute name matcher", OS);
 
   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;
 
     bool SemaHandler = Attr.getValueAsBit("SemaHandler");
     bool Ignored = Attr.getValueAsBit("Ignored");
     if (SemaHandler || Ignored) {
       // Attribute spellings can be shared between target-specific attributes,

         const std::string &RawSpelling = S.name();
         std::vector<StringMatcher::StringPair> *Matches = nullptr;
         std::string Spelling;
         const std::string &Variety = S.variety();
         if (Variety == "CXX11") {
           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")
           Matches = &Declspec;
         else if (Variety == "Microsoft")
           Matches = &Microsoft;
         else if (Variety == "Keyword")
           Matches = &Keywords;

   OS << "  if (AttributeList::AS_GNU == Syntax) {\n";
   StringMatcher("Name", GNU, OS).Emit();
   OS << "  } else if (AttributeList::AS_Declspec == Syntax) {\n";
   StringMatcher("Name", Declspec, OS).Emit();
   OS << "  } else if (AttributeList::AS_Microsoft == Syntax) {\n";
   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();
   OS << "  } else if (AttributeList::AS_Pragma == Syntax) {\n";
   StringMatcher("Name", Pragma, OS).Emit();
   OS << "  }\n";
   OS << "  return AttributeList::UnknownAttribute;\n"
      << "}\n";

   OS << StringRef(ContentStr).trim();
 
   OS << "\n\n";
 }
 
 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,
                                const DocumentationData &Doc, raw_ostream &OS) {
   // FIXME: there is no way to have a per-spelling category for the attribute
   // documentation. This may not be a limiting factor since the spellings
   // should generally be consistently applied across the category.
 

   // semantic characters are still acceptable.
   std::vector<std::string> Names;
 
   unsigned SupportedSpellings = 0;
   for (const auto &I : Spellings) {
     SpellingKind Kind = StringSwitch<SpellingKind>(I.variety())
                             .Case("GNU", GNU)
                             .Case("CXX11", CXX11)
+                            .Case("C2x", C2x)
                             .Case("Declspec", Declspec)
                             .Case("Microsoft", Microsoft)
                             .Case("Keyword", Keyword)
                             .Case("Pragma", Pragma);
 
     // Mask in the supported spelling.
     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();
 
     // If this name is the same as the heading, do not add it.
     if (Name != Heading)
       Names.push_back(Name);
   }
 

 
   if (!SupportedSpellings)
     PrintFatalError(Doc.Attribute->getLoc(),
                     "Attribute has no supported spellings; cannot be "
                     "documented");
 
   // 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";
   OS << "\", \"";
   if (SupportedSpellings & Pragma) OS << "X";
   OS << "\", \"";
   if (getPragmaAttributeSupport(Records).isAttributedSupported(*Doc.Attribute))
     OS << "X";