Stop claiming we support [[carries_dependency]]

[aaron.ballman]

Summary

The [[carries_dependency]] attribute was added to the standard in C++11, but implementations have (uniformly, as best I can tell) been ignoring this attribute for the past decade. In Clang, we would parse the attribute and otherwise do nothing useful with it (no additional analyses, no communication of the attribute to the backend, etc). As far as I know, we have no future plans to implement the semantics of the attribute. However, __has_cpp_attribute(carries_dependency) returns a nonzero value which suggests we actually do support the attribute and do useful things with it, especially because we documented that it might improve performance.

This removes all support for [[carries_dependency]] and treats it as an unknown attribute instead (the same as we do for other standard attributes we don't support, like [[no_unique_address]] on some targets). We now return zero from __has_cpp_attribute(carries_dependency), which matches the behavior of GCC.

I can find no evidence of user code that should be impacted by this. All uses of the GNU version of the attribute were in compiler test suites: https://sourcegraph.com/search?q=context:global+__attribute__%28%28carries_dependency%29%29+-file:.*test.*+-file:clang&patternType=standard&sm=1&groupBy=repo All uses of the C++ version of the attribute are also in compiler implementations or documentation: https://sourcegraph.com/search?q=context:global+%5B%5Bcarries_dependency%5D%5D+-file:.*test.*+-file:clang&patternType=standard&sm=1&groupBy=repo

Incidentally, this also helps people in WG21 build a case for deprecating and removing this attribute in a future revision of C++.

[cor3ntin]

Thanks for doing this Aaron.
Did you look in libc++ if they used it anywhere? (I assume they don't)

clang/docs/ReleaseNotes.rst

131

[philnik]

In D143670#4116118, @cor3ntin wrote:

Thanks for doing this Aaron.
Did you look in libc++ if they used it anywhere? (I assume they don't)

I'm not aware of any uses, and I would be quite surprised if it was used anywhere given that apparently nobody properly implemented it. IIUC this attribute is supposed to improve performance in some way, and we normally require a benchmark to show that some change actually does that if it claims to.

[erichkeane]

The guidance from EWG this week and in the past was that we are always required to 'parse and diagnose appertainment' of standard attributes, but not to enable __has_cpp_attribute unless we actually 'do' something with it. I intend/suggest we add a condition to the CXX tag of 'is supported' with some sort of conditional for checking diagnostic and O level (or just straight 'false' in this case).

clang/lib/Sema/SemaDecl.cpp

3324

Unfortunately EWG guidance doesn't let us do this, we still have to enforce appertainment/etc, even if we claim not to support this.

4038

Same here, we still have to carry it around.

clang/test/CXX/dcl.dcl/dcl.attr/dcl.attr.depend/p1.cpp

7

These tests still need to be here, __has_cpp_attribute or not.

[tahonermann]

The guidance from EWG this week and in the past was that we are always required to 'parse and diagnose appertainment' of standard attributes, but not to enable __has_cpp_attribute unless we actually 'do' something with it. I intend/suggest we add a condition to the CXX tag of 'is supported' with some sort of conditional for checking diagnostic and O level (or just straight 'false' in this case).

I've been thinking about the distinction here as well. I'm leaning towards the idea of Introducing a feature test macro for each standard attribute (e.g., __cpp_attr_carries_dependency that, If defined, indicates that the implementation is 1) aware of the attribute (won't diagnose uses of it as an unknown attribute) and 2) will perform syntax and appertainment checks. Conformance would require defining the feature test macro for corresponding standard versions (unless EWG can be convinced that standard attributes are optional). __has_cpp_attribute(XXX) would, of course, only be non-zero if the corresponding __cpp_attr_XXX feature test macro is defined.

[hubert.reinterpretcast]

clang/test/Preprocessor/has_attribute.cpp

51

I'd trust this when I see the change to [cpp.cond]/6 arrive in CWG.

[hubert.reinterpretcast]

I think it may be an option to use the gnu++* modes to do deliberately non-conforming things, but I believe there should be an RFC for that first.

[aaron.ballman]

In D143670#4116858, @erichkeane wrote:

The guidance from EWG this week and in the past was that we are always required to 'parse and diagnose appertainment' of standard attributes, but not to enable __has_cpp_attribute unless we actually 'do' something with it. I intend/suggest we add a condition to the CXX tag of 'is supported' with some sort of conditional for checking diagnostic and O level (or just straight 'false' in this case).

I'm aware of EWG's guidance, and EWG (and WG21) are aware of Clang's position regarding conformance in this area. It's unfortunate that EWG didn't consider implementer feedback or sibling committee feedback to be sufficiently compelling, but at the end of the day, we are the implementers not EWG, and we need to do what's best for us. This implementation is conforming to what the standard says. We're obligated to issue a diagnostic for the situations you identified and we do -- "attribute ignored" is a diagnostic that conveys exactly what we intend it to convey. Maybe someday we will improve conformance in this area but it is explicitly not a priority given that we're still trying to work on C++20 features three years after that standard was released. I suspect we'll get around to this particular "issue" roughly never (given the work, risks, and benefits) which is why WG21 was told this was a burden for us and that we would be conforming in this manner.

To be clear about this change specifically -- this is a consistency change. Our existing policy has always been that we do not silently ignore attributes unless they're actively harmful to diagnose as being ignored. [[carries_dependency]] isn't even used in practice, so it does not fall into the "harmful to diagnose" category. To date, we've silently accepted it without any intention of implementing the performance improvements it suggests are possible, and that's against our usual policy. What's more, this makes our behavior more self-consistent -- we already do syntactic ignorability of other standard attributes, like [[no_unique_address]] on some targets.

As we saw when we switched our default mode to C++17, compile time overhead is only getting worse with every release of C++. We do not need to keep the (admittedly small) compile time overhead on every C++ compilation to check for requirements of an attribute we will then ignore entirely. "You're using this wrong but we do nothing with it" is user-hostile behavior for attributes which are inherently non-portable (even the standard ones). I don't expect this to have a measurable impact on compile time overhead in practice, but it's hard to argue that there's value in testing every function parameter of every function declaration to see if it perhaps is using [[carries_dependency]] wrong. However, for future attributes like [[assume]], the expense of syntactic checking the argument expression is significant and nontrivial, and we should be self-consistent. (I expect we'll be one of the later C++ implementations to adopt that attribute given it cannot be *semantically* ignored due to potential for template instantiations, changing ABI, etc. We were bitten by WG21 adopting [[no_unique_address]] for C++20 and [[assume]] has already had at least one implementer push back on implementing it, so there's a very real chance we'll be in the same boat again.)

There's ample evidence that total ignorability is not unexpected behavior in practice, either -- the idiomatic way of using attributes is to use feature testing macros to provide various levels of fallback behavior. Note how the fallback clauses do not provide any syntactic checking for the attribute arguments and are defined in a way that semantic appertainment issues are silently ignored as well:

https://github.com/mozilla/gecko-dev/blob/master/third_party/highway/hwy/base.h#L159
https://github.com/pytorch/pytorch/blob/master/c10/util/Deprecated.h#L22
https://github.com/boostorg/config/blob/master/include/boost/config/detail/suffix.hpp#L701

Mozilla, pytorch, and boost are not doing anything unusual here and they are all examples of quite popular C++ projects; it seems to be rare that fallback code ever checks that the syntax of the argument is valid or that it’s being applied to the correct thing.

Given that these changes are conforming, make us more self-consistent with other C++ standard attributes we don't implement, and makes it less likely to introduce header incompatibilities with C (which has reaffirmed the need for syntactic ignorability of attribute for more than one of their implementations as well), I think we should move forward with these changes to [[carries_dependency]] regardless of EWG's guidance. We're following what we're obligated to follow for the standard requirements and WG21 is aware of this. Effectively, I believe our policy should be "follow the C rules for attributes and ignorability" because that does what we need at the moment; we can always revisit the decision later if we find we have the bandwidth.

Specific to this review, does anyone have evidence that we have actual users of [[carries_dependency]] who will be materially impacted by this change?

clang/test/Preprocessor/has_attribute.cpp

51

This is consistent with how we handle [[no_unique_address]] (see line 59).

[hubert.reinterpretcast]

clang/test/Preprocessor/has_attribute.cpp

51

Is that driven by compatibility concerns on the platform though? For example, we might be doing something on line 59 to match MSVC.

Do we know if GCC intends to make a similar change for carries_dependency? It may help to be more explicit about why our situation is different from GCC's.

[rsmith]

Until or unless a C++ DR permits us to define __has_cpp_attribute(carries_dependency) to any value other than 200809L, we have a conformance requirement to macro-expand this to that value. CWG2695 only adds a note, so it changes nothing in this regard. Similarly, we have a conformance requirement to emit a diagnostic on invalid uses of the attribute, and per our policy for -pedantic, we should produce an error for invalid uses under -pedantic-errors and not reject valid uses in that mode. So I think we still need all of the functionality that this patch removes for conformance reasons, for now at least. Maybe WG21 would be receptive to a paper making support of [[carries_dependency]] optional.

Conformance aside, the meaning of [[carries_dependency]] on a particular platform is an ABI requirement. On every platform that we support, the psABI does not specify any different handling for [[carries_dependency]] functions, so we *are* implementing the attribute completely and correctly on those targets, it just happens to be vacuous. If there were a target that defined a different ABI rule, or was anticipated to add such a different ABI rule (eg, due to some future PowerPC or ARM ABI change), then it would make sense to stop claiming support on those platforms until we implemented the behavior (I have the behavior of [[no_unique_address]] on MS ABI in mind here particularly). But I think it's not helpful to users to say we don't support it because it doesn't happen to make a difference on the current target, just it's not helpful to say we don't support [[no_unique_address]] just because it doesn't affect struct layout on a particular target, or -- more to the point -- it wouldn't be helpful to say we don't support consume memory ordering just because we don't get any benefit from it on the current target compared to acquire (and as a result, we lower consume to acquire). I think it's much better to let people unconditionally add [[carries_dependency]] (or [[no_unique_address]], or to use consume) when they mean it; that way, if they compile their code on both Clang and some other compiler that supports a target where the attribute does something, then they'll get the behavior they asked for. We shouldn't be encouraging people to wrap uses of standard attributes in macros.

That said, even though I think we should claim (vacuous) support for such cases, I think it would be reasonable to warn developers that they have no effect. For example, we could add a special-case sub-group of -Wignored-attribute to tell developers that "carries_dependency attribute has no effect", because they might be combining it with consume and expecting improved performance. It's probably even reasonable to turn such a warning on by default.

[aaron.ballman]

In D143670#4133677, @rsmith wrote:

Until or unless a C++ DR permits us to define __has_cpp_attribute(carries_dependency) to any value other than 200809L, we have a conformance requirement to macro-expand this to that value. CWG2695 only adds a note, so it changes nothing in this regard.

We don't yet have a C++ DR for this, but we do have EWG direction that such a DR is needed. At the end of the day, our behavior in Clang is inconsistent and this patch fixes that inconsistency. __has_cpp_attribute(no_unique_address) returns 0 on some targets for Clang already today. That cannot change without the risk of silently breaking ABI for users. This is why EWG is moving in the direction of making the value returned by the feature test macro be a matter of QoI. So in terms of behaving consistently, we're faced with a choice: potentially break users by returning nonzero for no_unique_address or stop returning nonzero for carries_dependency. GCC has always returned 0 for carries_dependency. Returning 0 makes Clang consistent with GCC for this specific attribute and makes Clang consistent with itself in terms of standard attributes.

Similarly, we have a conformance requirement to emit a diagnostic on invalid uses of the attribute, and per our policy for -pedantic, we should produce an error for invalid uses under -pedantic-errors and not reject valid uses in that mode. So I think we still need all of the functionality that this patch removes for conformance reasons, for now at least. Maybe WG21 would be receptive to a paper making support of [[carries_dependency]] optional.

The behavior of -pedantic-errors is an interesting point. We *conform* with an "attribute ignored" diagnostic as far as the standard is concerned (so there's no problem about conformance requirements) but it doesn't meet our usual behavior of giving an error in -pedantic-errors mode. We have quite a few other instances of missing pedantic errors and it'd be nice to not make that worse. However, given that we are missing plenty of other pedantic error diagnostics, I'm not certain that observation changes a whole lot in practice.

Conformance aside, the meaning of [[carries_dependency]] on a particular platform is an ABI requirement. On every platform that we support, the psABI does not specify any different handling for [[carries_dependency]] functions, so we *are* implementing the attribute completely and correctly on those targets, it just happens to be vacuous. If there were a target that defined a different ABI rule, or was anticipated to add such a different ABI rule (eg, due to some future PowerPC or ARM ABI change), then it would make sense to stop claiming support on those platforms until we implemented the behavior (I have the behavior of [[no_unique_address]] on MS ABI in mind here particularly). But I think it's not helpful to users to say we don't support it because it doesn't happen to make a difference on the current target, just it's not helpful to say we don't support [[no_unique_address]] just because it doesn't affect struct layout on a particular target, or -- more to the point -- it wouldn't be helpful to say we don't support consume memory ordering just because we don't get any benefit from it on the current target compared to acquire (and as a result, we lower consume to acquire). I think it's much better to let people unconditionally add [[carries_dependency]] (or [[no_unique_address]], or to use consume) when they mean it; that way, if they compile their code on both Clang and some other compiler that supports a target where the attribute does something, then they'll get the behavior they asked for. We shouldn't be encouraging people to wrap uses of standard attributes in macros.

Errr, I have exactly the opposite opinion as you on this. I do not think it helps users to claim vacuous support for an attribute -- that's a response only a compiler writer/committee member could appreciate. In my experience, users want to know "does the attribute do what it says on the tin" not "can the compiler trivially claim conformance". [[carries_dependency]] is an optimization hint; that we don't attempt to even pass the information along to the backend to try to vary optimization behavior means we're not doing what the attribute says on the tin. And given that standard attributes are inherently not portable nor backwards compatible, I think it's very reasonable to encourage people to wrap their use in macros.

Otherwise, what's the point to __has_cpp_attribute returning *anything* for a standard attribute? Users can check __cplusplus instead if the only answer they need to get from the feature test macro is "what version of the standard are you using?".

That said, even though I think we should claim (vacuous) support for such cases, I think it would be reasonable to warn developers that they have no effect. For example, we could add a special-case sub-group of -Wignored-attribute to tell developers that "carries_dependency attribute has no effect", because they might be combining it with consume and expecting improved performance. It's probably even reasonable to turn such a warning on by default.

I continue to believe the best approach here is the honest approach. We're not obligated to implement this attribute, we don't currently implement this attribute in any meaningful way, and so the best approach is to handle it the same as any other attribute we don't know or care about.

[erichkeane]

In D143670#4142351, @aaron.ballman wrote:

In D143670#4133677, @rsmith wrote:

Until or unless a C++ DR permits us to define __has_cpp_attribute(carries_dependency) to any value other than 200809L, we have a conformance requirement to macro-expand this to that value. CWG2695 only adds a note, so it changes nothing in this regard.

We don't yet have a C++ DR for this, but we do have EWG direction that such a DR is needed. At the end of the day, our behavior in Clang is inconsistent and this patch fixes that inconsistency. __has_cpp_attribute(no_unique_address) returns 0 on some targets for Clang already today. That cannot change without the risk of silently breaking ABI for users. This is why EWG is moving in the direction of making the value returned by the feature test macro be a matter of QoI. So in terms of behaving consistently, we're faced with a choice: potentially break users by returning nonzero for no_unique_address or stop returning nonzero for carries_dependency. GCC has always returned 0 for carries_dependency. Returning 0 makes Clang consistent with GCC for this specific attribute and makes Clang consistent with itself in terms of standard attributes.

Similarly, we have a conformance requirement to emit a diagnostic on invalid uses of the attribute, and per our policy for -pedantic, we should produce an error for invalid uses under -pedantic-errors and not reject valid uses in that mode. So I think we still need all of the functionality that this patch removes for conformance reasons, for now at least. Maybe WG21 would be receptive to a paper making support of [[carries_dependency]] optional.

The behavior of -pedantic-errors is an interesting point. We *conform* with an "attribute ignored" diagnostic as far as the standard is concerned (so there's no problem about conformance requirements) but it doesn't meet our usual behavior of giving an error in -pedantic-errors mode. We have quite a few other instances of missing pedantic errors and it'd be nice to not make that worse. However, given that we are missing plenty of other pedantic error diagnostics, I'm not certain that observation changes a whole lot in practice.

Conformance aside, the meaning of [[carries_dependency]] on a particular platform is an ABI requirement. On every platform that we support, the psABI does not specify any different handling for [[carries_dependency]] functions, so we *are* implementing the attribute completely and correctly on those targets, it just happens to be vacuous. If there were a target that defined a different ABI rule, or was anticipated to add such a different ABI rule (eg, due to some future PowerPC or ARM ABI change), then it would make sense to stop claiming support on those platforms until we implemented the behavior (I have the behavior of [[no_unique_address]] on MS ABI in mind here particularly). But I think it's not helpful to users to say we don't support it because it doesn't happen to make a difference on the current target, just it's not helpful to say we don't support [[no_unique_address]] just because it doesn't affect struct layout on a particular target, or -- more to the point -- it wouldn't be helpful to say we don't support consume memory ordering just because we don't get any benefit from it on the current target compared to acquire (and as a result, we lower consume to acquire). I think it's much better to let people unconditionally add [[carries_dependency]] (or [[no_unique_address]], or to use consume) when they mean it; that way, if they compile their code on both Clang and some other compiler that supports a target where the attribute does something, then they'll get the behavior they asked for. We shouldn't be encouraging people to wrap uses of standard attributes in macros.

Errr, I have exactly the opposite opinion as you on this. I do not think it helps users to claim vacuous support for an attribute -- that's a response only a compiler writer/committee member could appreciate. In my experience, users want to know "does the attribute do what it says on the tin" not "can the compiler trivially claim conformance". [[carries_dependency]] is an optimization hint; that we don't attempt to even pass the information along to the backend to try to vary optimization behavior means we're not doing what the attribute says on the tin. And given that standard attributes are inherently not portable nor backwards compatible, I think it's very reasonable to encourage people to wrap their use in macros.

Otherwise, what's the point to __has_cpp_attribute returning *anything* for a standard attribute? Users can check __cplusplus instead if the only answer they need to get from the feature test macro is "what version of the standard are you using?".

That said, even though I think we should claim (vacuous) support for such cases, I think it would be reasonable to warn developers that they have no effect. For example, we could add a special-case sub-group of -Wignored-attribute to tell developers that "carries_dependency attribute has no effect", because they might be combining it with consume and expecting improved performance. It's probably even reasonable to turn such a warning on by default.

I continue to believe the best approach here is the honest approach. We're not obligated to implement this attribute, we don't currently implement this attribute in any meaningful way, and so the best approach is to handle it the same as any other attribute we don't know or care about.

The last bit (intent of __has_cpp_attribute being that we 'do something useful with it') was the intent of the room in EWG. Note the term 'useful' was not used in the polls thanks to some CWG folks invading and telling us that 'useful' had meaning apart from what we meant :) That said, the subtlety of "we do exactly what you expect, which is NOTHING!" for carries-dependency wasn't brought up in the room.

It is ALSO the vote taken in EWG to make setting the value optional, see the poll "Ask CWG to change the definition of __has_cpp_attribute to permit 0, and place the suggested values in the 'recommended practice' of the individual attributes.", which gained consensus (https://github.com/cplusplus/papers/issues/1212).

[hubert.reinterpretcast]

Updated patch limited to changing the feature test macro value would match Varna meeting outcome (changes to allow macro to be 0 accepted as DR).

clang/docs/ReleaseNotes.rst

 -------------------
 
 C++ Language Changes in Clang
 -----------------------------
 - Improved ``-O0`` code generation for calls to ``std::forward_like``. Similarly to
   ``std::move, std::forward`` et al. it is now treated as a compiler builtin and implemented
   directly rather than instantiating the definition from the standard library.
 
+- Clang no longer claims to support the ``[[carries_dependency]]`` attribute.
+  We have not implemented any semantics for this attribute in the past decade,
+  have no plans to implement any in the future, and so returning nonzero from
+  ``__has_cpp_attribute`` was a disservice. The attribute is now treated as an
+  unknown attribute and ``__has_cpp_attribute(carries_dependency)`` now returns
+  zero.
+
 C++20 Feature Support
 ^^^^^^^^^^^^^^^^^^^^^
 
 C++2b Feature Support
 ^^^^^^^^^^^^^^^^^^^^^
 
 CUDA/HIP Language Changes in Clang
 ----------------------------------

clang/include/clang/Basic/Attr.td

def Blocks : InheritableAttr {
   let Documentation = [Undocumented];
 }
 
 def Bounded : IgnoredAttr {
   // Does not have a [[]] spelling because the attribute is ignored.
   let Spellings = [GNU<"bounded">];
 }
 
-def CarriesDependency : InheritableParamAttr {
-  let Spellings = [GNU<"carries_dependency">,
-                   CXX11<"","carries_dependency", 200809>];
-  let Subjects = SubjectList<[ParmVar, ObjCMethod, Function], ErrorDiag>;
-  let Documentation = [CarriesDependencyDocs];
-}
-
 def CDecl : DeclOrTypeAttr {
   let Spellings = [GCC<"cdecl">, Keyword<"__cdecl">, Keyword<"_cdecl">];
 //  let Subjects = [Function, ObjCMethod];
   let Documentation = [Undocumented];
 }
 
 // cf_audited_transfer indicates that the given function has been
 // audited and has been marked with the appropriate cf_consumed and

clang/include/clang/Basic/AttrDocs.td

 
 Sample usage:
 .. code-block:: c
 
   void maybeundeffunc(int __attribute__((maybe_undef))param);
   }];
 }
 
-def CarriesDependencyDocs : Documentation {
-  let Category = DocCatFunction;
-  let Content = [{
-The ``carries_dependency`` attribute specifies dependency propagation into and
-out of functions.
-
-When specified on a function or Objective-C method, the ``carries_dependency``
-attribute means that the return value carries a dependency out of the function,
-so that the implementation need not constrain ordering upon return from that
-function. Implementations of the function and its caller may choose to preserve
-dependencies instead of emitting memory ordering instructions such as fences.
-
-Note, this attribute does not change the meaning of the program, but may result
-in generation of more efficient code.
-  }];
-}
-
 def CPUSpecificCPUDispatchDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 The ``cpu_specific`` and ``cpu_dispatch`` attributes are used to define and
 resolve multiversioned functions. This form of multiversioning provides a
 mechanism for declaring versions across translation units and manually
 specifying the resolved function list. A specified CPU defines a set of minimum
 features that are required for the function to be called. The result of this is

clang/lib/Parse/ParseDeclCXX.cpp

   // Parse the closing paren for the argument list.
   T.consumeClose();
 }
 
 static bool IsBuiltInOrStandardCXX11Attribute(IdentifierInfo *AttrName,
                                               IdentifierInfo *ScopeName) {
   switch (
       ParsedAttr::getParsedKind(AttrName, ScopeName, ParsedAttr::AS_CXX11)) {
-  case ParsedAttr::AT_CarriesDependency:
   case ParsedAttr::AT_Deprecated:
   case ParsedAttr::AT_FallThrough:
   case ParsedAttr::AT_CXX11NoReturn:
   case ParsedAttr::AT_NoUniqueAddress:
   case ParsedAttr::AT_Likely:
   case ParsedAttr::AT_Unlikely:
     return true;
   case ParsedAttr::AT_WarnUnusedResult:

clang/lib/Sema/SemaDecl.cpp

   if (!foundAny) New->dropAttrs();
 }
 
 /// mergeParamDeclAttributes - Copy attributes from the old parameter
 /// to the new one.
 static void mergeParamDeclAttributes(ParmVarDecl *newDecl,
                                      const ParmVarDecl *oldDecl,
                                      Sema &S) {
-  // C++11 [dcl.attr.depend]p2:
-  //   The first declaration of a function shall specify the
-  //   carries_dependency attribute for its declarator-id if any declaration
-  //   of the function specifies the carries_dependency attribute.
-  const CarriesDependencyAttr *CDA = newDecl->getAttr<CarriesDependencyAttr>();
-  if (CDA && !oldDecl->hasAttr<CarriesDependencyAttr>()) {
-    S.Diag(CDA->getLocation(),
-           diag::err_carries_dependency_missing_on_first_decl) << 1/*Param*/;
-    // Find the first declaration of the parameter.
-    // FIXME: Should we build redeclaration chains for function parameters?
-    const FunctionDecl *FirstFD =
-      cast<FunctionDecl>(oldDecl->getDeclContext())->getFirstDecl();
-    const ParmVarDecl *FirstVD =
-      FirstFD->getParamDecl(oldDecl->getFunctionScopeIndex());
-    S.Diag(FirstVD->getLocation(),
-           diag::note_carries_dependency_missing_first_decl) << 1/*Param*/;
-  }
-
   if (!oldDecl->hasAttrs())
     return;
 
   bool foundAny = newDecl->hasAttrs();
 
   // Ensure that any moving of objects within the allocated map is
   // done before we process them.
   if (!foundAny) newDecl->setAttrs(AttrVec());

     //   attribute.
     if (const auto *NRA = New->getAttr<CXX11NoReturnAttr>())
       if (!Old->hasAttr<CXX11NoReturnAttr>()) {
         Diag(NRA->getLocation(), diag::err_attribute_missing_on_first_decl)
             << NRA;
         Diag(Old->getLocation(), diag::note_previous_declaration);
       }
 
-    // C++11 [dcl.attr.depend]p2:
-    //   The first declaration of a function shall specify the
-    //   carries_dependency attribute for its declarator-id if any declaration
-    //   of the function specifies the carries_dependency attribute.
-    const CarriesDependencyAttr *CDA = New->getAttr<CarriesDependencyAttr>();
-    if (CDA && !Old->hasAttr<CarriesDependencyAttr>()) {
-      Diag(CDA->getLocation(),
-           diag::err_carries_dependency_missing_on_first_decl) << 0/*Function*/;
-      Diag(Old->getFirstDecl()->getLocation(),
-           diag::note_carries_dependency_missing_first_decl) << 0/*Function*/;
-    }
-
     // (C++98 8.3.5p3):
     //   All declarations for a function shall agree exactly in both the
     //   return type and the parameter-type-list.
     // We also want to respect all the extended bits except noreturn.
 
     // noreturn should now match unless the old type info didn't have it.
     QualType OldQTypeForComparison = OldQType;
     if (!OldTypeInfo.getNoReturn() && NewTypeInfo.getNoReturn()) {

clang/lib/Sema/SemaDeclAttr.cpp

       return;
     }
     count++;
   }
 
   D->addAttr(::new (S.Context) VecReturnAttr(S.Context, AL));
 }
 
-static void handleDependencyAttr(Sema &S, Scope *Scope, Decl *D,
-                                 const ParsedAttr &AL) {
-  if (isa<ParmVarDecl>(D)) {
-    // [[carries_dependency]] can only be applied to a parameter if it is a
-    // parameter of a function declaration or lambda.
-    if (!(Scope->getFlags() & clang::Scope::FunctionDeclarationScope)) {
-      S.Diag(AL.getLoc(),
-             diag::err_carries_dependency_param_not_function_decl);
-      return;
-    }
-  }
-
-  D->addAttr(::new (S.Context) CarriesDependencyAttr(S.Context, AL));
-}
-
 static void handleUnusedAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   bool IsCXX17Attr = AL.isCXX11Attribute() && !AL.getScopeName();
 
   // If this is spelled as the standard C++17 attribute, but not in C++17, warn
   // about using it as an extension.
   if (!S.getLangOpts().CPlusPlus17 && IsCXX17Attr)
     S.Diag(AL.getLoc(), diag::ext_cxx17_attr) << AL;
 

     handleTLSModelAttr(S, D, AL);
     break;
   case ParsedAttr::AT_Annotate:
     handleAnnotateAttr(S, D, AL);
     break;
   case ParsedAttr::AT_Availability:
     handleAvailabilityAttr(S, D, AL);
     break;
-  case ParsedAttr::AT_CarriesDependency:
-    handleDependencyAttr(S, scope, D, AL);
-    break;
   case ParsedAttr::AT_CPUDispatch:
   case ParsedAttr::AT_CPUSpecific:
     handleCPUSpecificAttr(S, D, AL);
     break;
   case ParsedAttr::AT_Common:
     handleCommonAttr(S, D, AL);
     break;
   case ParsedAttr::AT_CUDAConstant:

clang/test/CXX/dcl.dcl/dcl.attr/dcl.attr.depend/p1.cpp

 // RUN: %clang_cc1 -verify -std=c++11 %s
+// expected-no-diagnostics
 
-[[carries_dependency, carries_dependency]] int m1(); // ok
-[[carries_dependency]] [[carries_dependency]] int m2(); // ok
-[[carries_dependency()]] int m3(); // expected-error {{attribute 'carries_dependency' cannot have an argument list}}
-
-[[carries_dependency]] void f1(); // FIXME: warn here
-[[carries_dependency]] int f2(); // ok
-int f3(int param [[carries_dependency]]); // ok
-[[carries_dependency]] int (*f4)(); // expected-error {{'carries_dependency' attribute only applies to parameters, Objective-C methods, and functions}}
-int (*f5 [[carries_dependency]])(); // expected-error {{'carries_dependency' attribute only applies to}}
-int (*f6)() [[carries_dependency]]; // expected-error {{'carries_dependency' attribute cannot be applied to types}}
-int (*f7)(int n [[carries_dependency]]); // expected-error {{'[[carries_dependency]]' attribute only allowed on parameter in a function declaration}}
-int (((f8)))(int n [[carries_dependency]]); // ok
-int (*f9(int n))(int n [[carries_dependency]]); // expected-error {{'[[carries_dependency]]' attribute only allowed on parameter in a function declaration}}
-int typedef f10(int n [[carries_dependency]]); // expected-error {{'[[carries_dependency]]' attribute only allowed on parameter in a function declaration}}
-using T = int(int n [[carries_dependency]]); // expected-error {{'[[carries_dependency]]' attribute only allowed on parameter in a function declaration}}
-struct S {
-  [[carries_dependency]] int f(int n [[carries_dependency]]); // ok
-  int (*p)(int n [[carries_dependency]]); // expected-error {{'[[carries_dependency]]' attribute only allowed on parameter in a function declaration}}
-};
-void f() {
-  [[carries_dependency]] int f(int n [[carries_dependency]]); // ok
-  [[carries_dependency]] // expected-error {{'carries_dependency' attribute only applies to}}
-      int (*p)(int n [[carries_dependency]]); // expected-error {{'[[carries_dependency]]' attribute only allowed on parameter in a function declaration}}
-}
-
-auto l1 = [](int n [[carries_dependency]]) {};
-// There's no way to write a lambda such that the return value carries
-// a dependency, because an attribute applied to the lambda appertains to
-// the *type* of the operator() function, not to the function itself.
-auto l2 = []() [[carries_dependency]] {}; // expected-error {{'carries_dependency' attribute cannot be applied to types}}
+// We do not do anything with [[carries_dependency]], so we do not
+// claim to support it. We ignore it as we would any other unknown
+// attribute.
+#if __has_cpp_attribute(carries_dependency)
+#error "Did not expect to support carries_dependency"
+#endif

clang/test/CXX/dcl.dcl/dcl.attr/dcl.attr.depend/p2.cpp

-// RUN: %clang_cc1 -verify -std=c++11 %s
-
-int f(int); // expected-note 2{{declaration missing '[[carries_dependency]]' attribute is here}}
-[[carries_dependency]] int f(int); // expected-error {{function declared '[[carries_dependency]]' after its first declaration}}
-int f(int n [[carries_dependency]]); // expected-error {{parameter declared '[[carries_dependency]]' after its first declaration}}
-
-int g([[carries_dependency]] int n); // expected-note {{declaration missing '[[carries_dependency]]' attribute is here}}
-int g(int);
-[[carries_dependency]] int g(int); // expected-error {{function declared '[[carries_dependency]]' after its first declaration}}
-int g(int n [[carries_dependency]]);
-
-int h [[carries_dependency]]();
-int h();
-[[carries_dependency]] int h();

clang/test/CodeCompletion/attr.cpp

 int a [[gnu::used]];
 // RUN: %clang_cc1 -code-completion-at=%s:%(line-1):9 %s | FileCheck --check-prefix=STD %s
-// STD:     COMPLETION: Pattern : __carries_dependency__
 // STD-NOT: COMPLETION: Pattern : __convergent__
 // STD:     COMPLETION: Pattern : __gnu__::__used__
 // STD-NOT: COMPLETION: Pattern : __gnu__::used
 // STD-NOT: COMPLETION: Pattern : __used__
 // STD:     COMPLETION: Pattern : _Clang::__convergent__
-// STD:     COMPLETION: Pattern : carries_dependency
 // STD-NOT: COMPLETION: Pattern : clang::called_once
 // STD:     COMPLETION: Pattern : clang::convergent
 // STD-NOT: COMPLETION: Pattern : convergent
 // STD-NOT: COMPLETION: Pattern : gnu::__used__
 // STD:     COMPLETION: Pattern : gnu::abi_tag(<#Tags...#>)
 // STD:     COMPLETION: Pattern : gnu::alias(<#Aliasee#>)
 // STD:     COMPLETION: Pattern : gnu::used
 // STD-NOT: COMPLETION: Pattern : used
-// RUN: %clang_cc1 -code-completion-at=%s:%(line-17):9 -xobjective-c++ %s | FileCheck --check-prefix=STD-OBJC %s
+// RUN: %clang_cc1 -code-completion-at=%s:%(line-15):9 -xobjective-c++ %s | FileCheck --check-prefix=STD-OBJC %s
 // STD-OBJC: COMPLETION: Pattern : clang::called_once
-// RUN: %clang_cc1 -code-completion-at=%s:%(line-19):14 %s | FileCheck --check-prefix=STD-NS %s
+// RUN: %clang_cc1 -code-completion-at=%s:%(line-17):14 %s | FileCheck --check-prefix=STD-NS %s
 // STD-NS-NOT: COMPLETION: Pattern : __used__
-// STD-NS-NOT: COMPLETION: Pattern : carries_dependency
 // STD-NS-NOT: COMPLETION: Pattern : clang::convergent
 // STD-NS-NOT: COMPLETION: Pattern : convergent
 // STD-NS-NOT: COMPLETION: Pattern : gnu::used
 // STD-NS:     COMPLETION: Pattern : used
 int b [[__gnu__::used]];
 // RUN: %clang_cc1 -code-completion-at=%s:%(line-1):18 %s | FileCheck --check-prefix=STD-NSU %s
 // STD-NSU:     COMPLETION: Pattern : __used__
 // STD-NSU-NOT: COMPLETION: Pattern : used
 
 int c [[using gnu: used]];
 // RUN: %clang_cc1 -code-completion-at=%s:%(line-1):15 %s | FileCheck --check-prefix=STD-USING %s
 // STD-USING:     COMPLETION: __gnu__
 // STD-USING:     COMPLETION: _Clang
-// STD-USING-NOT: COMPLETION: Pattern : carries_dependency
 // STD-USING:     COMPLETION: clang
 // STD-USING-NOT: COMPLETION: Pattern : clang::
 // STD-USING-NOT: COMPLETION: Pattern : gnu::
 // STD-USING:     COMPLETION: gnu
 // RUN: %clang_cc1 -code-completion-at=%s:%(line-9):20 %s | FileCheck --check-prefix=STD-NS %s
 
 int d __attribute__((used));
 // RUN: %clang_cc1 -code-completion-at=%s:%(line-1):22 %s | FileCheck --check-prefix=GNU %s
-// GNU:     COMPLETION: Pattern : __carries_dependency__
 // GNU:     COMPLETION: Pattern : __convergent__
 // GNU-NOT: COMPLETION: Pattern : __gnu__::__used__
 // GNU:     COMPLETION: Pattern : __used__
 // GNU-NOT: COMPLETION: Pattern : _Clang::__convergent__
-// GNU:     COMPLETION: Pattern : carries_dependency
 // GNU-NOT: COMPLETION: Pattern : clang::convergent
 // GNU:     COMPLETION: Pattern : convergent
 // GNU-NOT: COMPLETION: Pattern : gnu::used
 // GNU:     COMPLETION: Pattern : used
 
 #pragma clang attribute push (__attribute__((internal_linkage)), apply_to=variable)
 int e;
 #pragma clang attribute pop

clang/test/Misc/pragma-attribute-supported-attributes-list.test

 // CHECK-NEXT: CUDAHost (SubjectMatchRule_function)
 // CHECK-NEXT: CUDALaunchBounds (SubjectMatchRule_objc_method, SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: CUDAShared (SubjectMatchRule_variable)
 // CHECK-NEXT: CXX11NoReturn (SubjectMatchRule_function)
 // CHECK-NEXT: CallableWhen (SubjectMatchRule_function_is_member)
 // CHECK-NEXT: Callback (SubjectMatchRule_function)
 // CHECK-NEXT: CalledOnce (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: Capability (SubjectMatchRule_record, SubjectMatchRule_type_alias)
-// CHECK-NEXT: CarriesDependency (SubjectMatchRule_variable_is_parameter, SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: Cleanup (SubjectMatchRule_variable_is_local)
 // CHECK-NEXT: CmseNSEntry (SubjectMatchRule_function)
 // CHECK-NEXT: Cold (SubjectMatchRule_function)
 // CHECK-NEXT: Common (SubjectMatchRule_variable)
 // CHECK-NEXT: ConstInit (SubjectMatchRule_variable_is_global)
 // CHECK-NEXT: Constructor (SubjectMatchRule_function)
 // CHECK-NEXT: Consumable (SubjectMatchRule_record)
 // CHECK-NEXT: ConsumableAutoCast (SubjectMatchRule_record)

clang/test/Parser/cxx0x-attributes.cpp

namespace arguments {
   // expected-warning@-1 {{use of the 'deprecated' attribute is a C++14 extension}}
 }
 
 // Forbid attributes on decl specifiers.
 unsigned [[gnu::used]] static int [[gnu::unused]] v1; // expected-error {{'unused' attribute cannot be applied to types}} \
            expected-error {{an attribute list cannot appear here}}
 typedef [[gnu::used]] unsigned long [[gnu::unused]] v2; // expected-error {{'unused' attribute cannot be applied to types}} \
           expected-error {{an attribute list cannot appear here}}
-int [[carries_dependency]] foo(int [[carries_dependency]] x); // expected-error 2{{'carries_dependency' attribute cannot be applied to types}}
+int [[carries_dependency]] foo(int [[carries_dependency]] x); // expected-warning 2{{unknown attribute 'carries_dependency' ignored}}
 
 // Forbid [[gnu::...]] attributes on declarator chunks.
 int *[[gnu::unused]] v3; // expected-warning {{attribute 'unused' ignored}}
 int v4[2][[gnu::unused]]; // expected-warning {{attribute 'unused' ignored}}
 int v5()[[gnu::unused]]; // expected-warning {{attribute 'unused' ignored}}
 
 [[attribute_declaration]]; // expected-warning {{unknown attribute 'attribute_declaration' ignored}}
 [[noreturn]]; // expected-error {{'noreturn' attribute only applies to functions}}
-[[carries_dependency]]; // expected-error {{'carries_dependency' attribute only applies to parameters, Objective-C methods, and functions}}
+[[carries_dependency]]; // expected-warning {{unknown attribute 'carries_dependency' ignored}}
 
 class A {
   A([[gnu::unused]] int a);
 };
 A::A([[gnu::unused]] int a) {}
 
 namespace GccConst {
   // GCC's tokenizer treats const and __const as the same token.

clang/test/Parser/cxx11-stmt-attributes.cpp

void foo(int i) {
   [[unknown_attribute]] goto here; // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
   [[unknown_attribute]] here: // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
 
   [[unknown_attribute]] try { // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
   } catch (...) {
   }
 
   [[unknown_attribute]] return; // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
-   
 
   alignas(8) ; // expected-error {{'alignas' attribute cannot be applied to a statement}}
   [[noreturn]] { } // expected-error {{'noreturn' attribute cannot be applied to a statement}}
   [[noreturn]] if (0) { } // expected-error {{'noreturn' attribute cannot be applied to a statement}}
   [[noreturn]] for (;;); // expected-error {{'noreturn' attribute cannot be applied to a statement}}
   [[noreturn]] do { // expected-error {{'noreturn' attribute cannot be applied to a statement}}
     [[unavailable]] continue; // expected-warning {{unknown attribute 'unavailable' ignored}}
   } while (0);
   [[unknown_attributqqq]] while (0); // expected-warning {{unknown attribute 'unknown_attributqqq' ignored}}
   // TODO: remove 'qqq' part and enjoy 'empty loop body' warning here (DiagnoseEmptyLoopBody)
 
   [[unknown_attribute]] while (0); // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
 
   [[unused]] switch (i) { // expected-warning {{unknown attribute 'unused' ignored}}
     [[uuid]] case 0: // expected-warning {{unknown attribute 'uuid' ignored}}
     [[visibility]] default: // expected-warning {{unknown attribute 'visibility' ignored}}
-      [[carries_dependency]] break; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+      [[gnu::nonnull]] break; // expected-error {{'nonnull' attribute cannot be applied to a statement}}
   }
 
   [[fastcall]] goto there; // expected-warning {{unknown attribute 'fastcall' ignored}}
   [[noinline]] there: // expected-warning {{unknown attribute 'noinline' ignored}}
 
   [[lock_returned]] try { // expected-warning {{unknown attribute 'lock_returned' ignored}}
   } catch (...) {
   }
 
   [[weakref]] return; // expected-warning {{unknown attribute 'weakref' ignored}}
 
-  [[carries_dependency]] ; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-  [[carries_dependency]] { } // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-  [[carries_dependency]] if (0) { } // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-  [[carries_dependency]] for (;;); // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-  [[carries_dependency]] do { // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-    [[carries_dependency]] continue; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}} ignored}}
+  [[gnu::nonnull]] ; // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+  [[gnu::nonnull]] { } // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+  [[gnu::nonnull]] if (0) { } // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+  [[gnu::nonnull]] for (;;); // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+  [[gnu::nonnull]] do { // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+    [[gnu::nonnull]] continue; // expected-error {{'nonnull' attribute cannot be applied to a statement}} ignored}}
   } while (0);
-  [[carries_dependency]] while (0); // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  [[gnu::nonnull]] while (0); // expected-error {{'nonnull' attribute cannot be applied to a statement}}
 
-  [[carries_dependency]] switch (i) { // expected-error {{'carries_dependency' attribute cannot be applied to a statement}} ignored}}
-    [[carries_dependency]] case 0: // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-    [[carries_dependency]] default: // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-      [[carries_dependency]] break; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  [[gnu::nonnull]] switch (i) { // expected-error {{'nonnull' attribute cannot be applied to a statement}} ignored}}
+    [[gnu::nonnull]] case 0: // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+    [[gnu::nonnull]] default: // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+      [[gnu::nonnull]] break; // expected-error {{'nonnull' attribute cannot be applied to a statement}}
   }
 
-  [[carries_dependency]] goto here; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  [[gnu::nonnull]] goto here; // expected-error {{'nonnull' attribute cannot be applied to a statement}}
 
-  [[carries_dependency]] try { // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  [[gnu::nonnull]] try { // expected-error {{'nonnull' attribute cannot be applied to a statement}}
   } catch (...) {
   }
 
-  [[carries_dependency]] return; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  [[gnu::nonnull]] return; // expected-error {{'nonnull' attribute cannot be applied to a statement}}
 
   {
     [[ ]] // expected-error {{an attribute list cannot appear here}}
 #pragma STDC FP_CONTRACT ON // expected-error {{can only appear at file scope or at the start of a compound statement}}
 #pragma clang fp contract(fast) // expected-error {{can only appear at file scope or at the start of a compound statement}}
   }
 }

clang/test/Parser/stmt-attributes.c

void foo(int i) {
   }
   while (0)
     ;
   __attribute__((unknown_attribute)) while (0); // expected-warning {{unknown attribute 'unknown_attribute' ignored}}
 
   __attribute__((unused)) switch (i) {         // expected-error {{'unused' attribute cannot be applied to a statement}}
   __attribute__((uuid)) case 0:                // expected-warning {{unknown attribute 'uuid' ignored}}
   __attribute__((visibility(""))) default:         // expected-error {{'visibility' attribute cannot be applied to a statement}}
-    __attribute__((carries_dependency)) break; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+    __attribute__((nonnull)) break; // expected-error {{'nonnull' attribute cannot be applied to a statement}}
   }
 
   __attribute__((fastcall)) goto there; // expected-error {{'fastcall' attribute cannot be applied to a statement}}
   __attribute__((noinline)) there :     // expected-warning {{'noinline' attribute only applies to functions and statements}}
 
                                     __attribute__((weakref)) return; // expected-error {{'weakref' attribute only applies to variables and functions}}
 
-  __attribute__((carries_dependency));            // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-  __attribute__((carries_dependency)) {}          // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-  __attribute__((carries_dependency)) if (0) {}   // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-  __attribute__((carries_dependency)) for (;;);   // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-  __attribute__((carries_dependency)) do {        // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-    __attribute__((carries_dependency)) continue; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}} ignored}}
+  __attribute__((nonnull));            // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+  __attribute__((nonnull)) {}          // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+  __attribute__((nonnull)) if (0) {}   // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+  __attribute__((nonnull)) for (;;);   // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+  __attribute__((nonnull)) do {        // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+    __attribute__((nonnull)) continue; // expected-error {{'nonnull' attribute cannot be applied to a statement}} ignored}}
   }
   while (0)
     ;
-  __attribute__((carries_dependency)) while (0); // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  __attribute__((nonnull)) while (0); // expected-error {{'nonnull' attribute cannot be applied to a statement}}
 
-  __attribute__((carries_dependency)) switch (i) { // expected-error {{'carries_dependency' attribute cannot be applied to a statement}} ignored}}
-  __attribute__((carries_dependency)) case 0:      // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-  __attribute__((carries_dependency)) default:     // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
-    __attribute__((carries_dependency)) break;     // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  __attribute__((nonnull)) switch (i) { // expected-error {{'nonnull' attribute cannot be applied to a statement}} ignored}}
+  __attribute__((nonnull)) case 0:      // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+  __attribute__((nonnull)) default:     // expected-error {{'nonnull' attribute cannot be applied to a statement}}
+    __attribute__((nonnull)) break;     // expected-error {{'nonnull' attribute cannot be applied to a statement}}
   }
 
-  __attribute__((carries_dependency)) goto here; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  __attribute__((nonnull)) goto here; // expected-error {{'nonnull' attribute cannot be applied to a statement}}
 
-  __attribute__((carries_dependency)) return; // expected-error {{'carries_dependency' attribute cannot be applied to a statement}}
+  __attribute__((nonnull)) return; // expected-error {{'nonnull' attribute cannot be applied to a statement}}
 }
 
 void bar(void);
 
 void foobar(void) {
   __attribute__((nomerge)) bar();
   __attribute__(()) bar();                // expected-error {{expected identifier or '('}}
   __attribute__((unused, nomerge)) bar(); // expected-error {{expected identifier or '('}}

clang/test/Preprocessor/has_attribute.cpp

 // RUN: %clang_cc1 -triple i386-unknown-unknown -fms-compatibility -std=c++11 -E -P %s -o - | FileCheck %s --check-prefixes=CHECK,ITANIUM --implicit-check-not=:
 // RUN: %clang_cc1 -triple i386-windows -fms-compatibility -std=c++11 -E -P %s -o - | FileCheck %s --check-prefixes=CHECK,WINDOWS --implicit-check-not=:
 
 #define CXX11(x) x: __has_cpp_attribute(x)
+#define NOT_SUPPORTED(x) x: __has_cpp_attribute(x)
 
 // CHECK: clang::fallthrough: 201603L
 CXX11(clang::fallthrough)
 
 // CHECK: selectany: 0
 CXX11(selectany)
 
 // The attribute name can be bracketed with double underscores.

 // Test that C++11, target-specific attributes behave properly.
 
 // CHECK: gnu::mips16: 0
 CXX11(gnu::mips16)
 
 // Test for standard attributes as listed in C++2a [cpp.cond] paragraph 6.
 
 CXX11(assert)
-CXX11(carries_dependency)
+NOT_SUPPORTED(carries_dependency)
 CXX11(deprecated)
 CXX11(ensures)
 CXX11(expects)
 CXX11(fallthrough)
 CXX11(likely)
 CXX11(maybe_unused)
 CXX11(no_unique_address)
 CXX11(nodiscard)
 CXX11(noreturn)
 CXX11(unlikely)
 // FIXME(201806L) CHECK: assert: 0
-// CHECK: carries_dependency: 200809L
+// CHECK: carries_dependency: 0
 // CHECK: deprecated: 201309L
 // FIXME(201806L) CHECK: ensures: 0
 // FIXME(201806L) CHECK: expects: 0
 // CHECK: fallthrough: 201603L
 // CHECK: likely: 201803L
 // CHECK: maybe_unused: 201603L
 // ITANIUM: no_unique_address: 201803L
 // WINDOWS: no_unique_address: 0

clang/test/SemaCXX/attr-cxx0x.cpp

 static_assert(alignof(align_class_template<8>) == 8, "template's alignment is wrong");
 static_assert(alignof(align_class_template<16>) == 16, "template's alignment is wrong");
 static_assert(alignof(align_class_temp_pack_type<short, int, long>) == alignof(long), "template's alignment is wrong");
 static_assert(alignof(align_class_temp_pack_expr<8, 16, 32>) == 32, "template's alignment is wrong");
 static_assert(alignof(outer<int,char>::inner<double,short>) == alignof(int) * alignof(double), "template's alignment is wrong");
 
 static_assert(alignof(int(int)) >= 1, "alignof(function) not positive"); // expected-error{{invalid application of 'alignof' to a function type}}
 
-[[__carries_dependency__]]
+[[__carries_dependency__]] // expected-warning {{unknown attribute '__carries_dependency__' ignored}}
 void func(void);
 
 alignas(4) auto PR19252 = 0;