[clang] adds a discardable attribute

[cjdb]

Summary

Although the default behaviour for C and C++ is to not diagnose ignored function
calls, we can make this the default by using `#pragma clang attribute
push([[nodiscard]], apply_to = function)`. When we have a function that can
have its value discarded, we can use [[clang::discardable]] to indicate that
the `[[nodiscard]]` attribute should be ignored.

[[clang::discardable]] can be placed anywhere [[nodiscard]] is allowed,
but the presence of either is prioritised when it's applied to a callable.

[cjdb]

undoes editor autotrimming of spaces

[aaron.ballman]

When we have a function that can have its value discarded, we can use [[clang::discardable]] to indicate that the [[nodiscard]] attribute should be ignored.

Alternatively, you can scope the pragma and declarations appropriately and then we don't need to add a new attribute. Is there a reason that wouldn't work for you?

(This attribute would be interesting to consider if we added a feature flag like -fdiagnose-discarded-results where the default is as-if everything was declared nodiscard and then you could mark the APIs with [[clang::discardable]] for the few whose results don't matter. However, that's also a much bigger feature because system headers are a challenge.)

[cjdb]

In D129835#3655487, @aaron.ballman wrote:

When we have a function that can have its value discarded, we can use [[clang::discardable]] to indicate that the [[nodiscard]] attribute should be ignored.

Alternatively, you can scope the pragma and declarations appropriately and then we don't need to add a new attribute. Is there a reason that wouldn't work for you?

A key problem here (IMO) is that this requires manually pushing and popping the pragma as it is required. With [[discardable]] one just needs to push/pop at the extremes of a file (and if a future version of module maps supports global pragmas for a module, there too, but that's a discussion that requires a design doc).

It's also good for documenting "hey you can discard this thing in my sea of nodiscard interfaces" on the interface itself. That coupling is also good for correctness because it means something can't accidentally slip in/out of the pragma's scope.

(This attribute would be interesting to consider if we added a feature flag like -fdiagnose-discarded-results where the default is as-if everything was declared nodiscard and then you could mark the APIs with [[clang::discardable]] for the few whose results don't matter. However, that's also a much bigger feature because system headers are a challenge.)

The primary reason for me wanting to add this attribute comes from my libc++ days, where I wanted to mark whatever made sense as nodiscard. @ldionne was in favour in principle, but against in practice; noting that nodiscard would clutter the interface too much, and it'd be better if the situation were reversed (which is what this patch does). I think adding this is still a good step for getting us to a world where -fdiagnose-discarded-results can be a real consideration, especially if libc++ and llvm-libc adopt it.

[aaron.ballman]

In D129835#3655548, @cjdb wrote:

In D129835#3655487, @aaron.ballman wrote:

When we have a function that can have its value discarded, we can use [[clang::discardable]] to indicate that the [[nodiscard]] attribute should be ignored.

Alternatively, you can scope the pragma and declarations appropriately and then we don't need to add a new attribute. Is there a reason that wouldn't work for you?

A key problem here (IMO) is that this requires manually pushing and popping the pragma as it is required.

That's a feature to me, not a bug. It means you have to actually think about what you're doing instead of being surprised. This is the same reason our community standards want you to keep anonymous namespaces as small as possible -- it's too easy to have absolutely no idea about the behavior when you're in the middle of a block of code and the relevant part is off-screen somewhere.

With [[discardable]] one just needs to push/pop at the extremes of a file (and if a future version of module maps supports global pragmas for a module, there too, but that's a discussion that requires a design doc).

I understood that, I just don't think that's a good thing. This is basically an attribute that says "I know we said we wanted everything here to be nodiscard, but JUST KIDDING not this one!" which is not a very clean approach to writing headers.

It's also good for documenting "hey you can discard this thing in my sea of nodiscard interfaces" on the interface itself. That coupling is also good for correctness because it means something can't accidentally slip in/out of the pragma's scope.

I'd like to see some examples of that. In my experience, attributes are most often hidden behind macros which are sometimes then combined with other macros, etc, so whether the attribute is effective or not is already not always obvious from the interface; I don't see how this will move the needle.

(This attribute would be interesting to consider if we added a feature flag like -fdiagnose-discarded-results where the default is as-if everything was declared nodiscard and then you could mark the APIs with [[clang::discardable]] for the few whose results don't matter. However, that's also a much bigger feature because system headers are a challenge.)

The primary reason for me wanting to add this attribute comes from my libc++ days, where I wanted to mark whatever made sense as nodiscard. @ldionne was in favour in principle, but against in practice; noting that nodiscard would clutter the interface too much, and it'd be better if the situation were reversed (which is what this patch does). I think adding this is still a good step for getting us to a world where -fdiagnose-discarded-results can be a real consideration, especially if libc++ and llvm-libc adopt it.

Yes, I wish the default were correct as well, but it's not and it won't ever be corrected for practicality reasons. I don't know what libc++'s goals are in terms of other compilers, but it seems like using a clang-specific pragma would be making it more difficult to use libc++ with any other compiler.

[cjdb]

With [[discardable]] one just needs to push/pop at the extremes of a file (and if a future version of module maps supports global pragmas for a module, there too, but that's a discussion that requires a design doc).

I understood that, I just don't think that's a good thing. This is basically an attribute that says "I know we said we wanted everything here to be nodiscard, but JUST KIDDING not this one!" which is not a very clean approach to writing headers.

@aaron.ballman Ugh, I've finally come up with a good use-case for [[discardable]].

class [[nodiscard]] iterator {
public:
  // usual iterator stuff

  [[clang::discardable]] iterator operator++(int);
  [[clang::discardable]] iterator operator--(int);
};

I hate it, but the alternative is to decorate everything else with [[nodiscard]] just to facilitate these two operators. It's a compelling use-case, but I'm not sure if it's compelling enough on its own. WDYT?
(I personally think that those two should be nodiscard, but i++ is pervasive enough that it might never be practical to correct.)

[aaron.ballman]

In D129835#4287866, @cjdb wrote:

With [[discardable]] one just needs to push/pop at the extremes of a file (and if a future version of module maps supports global pragmas for a module, there too, but that's a discussion that requires a design doc).

I understood that, I just don't think that's a good thing. This is basically an attribute that says "I know we said we wanted everything here to be nodiscard, but JUST KIDDING not this one!" which is not a very clean approach to writing headers.

@aaron.ballman Ugh, I've finally come up with a good use-case for [[discardable]].

class [[nodiscard]] iterator {
public:
  // usual iterator stuff

  [[clang::discardable]] iterator operator++(int);
  [[clang::discardable]] iterator operator--(int);
};

I hate it, but the alternative is to decorate everything else with [[nodiscard]] just to facilitate these two operators. It's a compelling use-case, but I'm not sure if it's compelling enough on its own. WDYT?
(I personally think that those two should be nodiscard, but i++ is pervasive enough that it might never be practical to correct.)

I'm still not super motivated because I think this encourages a confused design, because marking a *type* as nodiscard is making a promise about the type as a whole. That asserts there's *never* a valid time to ignore a value of the type. If you have times when that type is reasonable to ignore, then the type isn't actually non-discardable, and you should mark the methods returning the type. (IOW, "nodiscard" is part of the contract for the type in some limited ways even if it's not reflected by the type system.)

What's more, I think iterator is a case where it'd be a mistake to mark the type nodiscard, because there are plenty times when it's valid to ignore the type (consider many of the functions in <algorithm>, like std::copy()). I think it's more appropriate to mark the functions returning an iterator rather than the type itself.

[erichkeane]

In D129835#4288240, @aaron.ballman wrote:

In D129835#4287866, @cjdb wrote:

With [[discardable]] one just needs to push/pop at the extremes of a file (and if a future version of module maps supports global pragmas for a module, there too, but that's a discussion that requires a design doc).

I understood that, I just don't think that's a good thing. This is basically an attribute that says "I know we said we wanted everything here to be nodiscard, but JUST KIDDING not this one!" which is not a very clean approach to writing headers.

@aaron.ballman Ugh, I've finally come up with a good use-case for [[discardable]].

class [[nodiscard]] iterator {
public:
  // usual iterator stuff

  [[clang::discardable]] iterator operator++(int);
  [[clang::discardable]] iterator operator--(int);
};

I hate it, but the alternative is to decorate everything else with [[nodiscard]] just to facilitate these two operators. It's a compelling use-case, but I'm not sure if it's compelling enough on its own. WDYT?
(I personally think that those two should be nodiscard, but i++ is pervasive enough that it might never be practical to correct.)

I'm still not super motivated because I think this encourages a confused design, because marking a *type* as nodiscard is making a promise about the type as a whole. That asserts there's *never* a valid time to ignore a value of the type. If you have times when that type is reasonable to ignore, then the type isn't actually non-discardable, and you should mark the methods returning the type. (IOW, "nodiscard" is part of the contract for the type in some limited ways even if it's not reflected by the type system.)

What's more, I think iterator is a case where it'd be a mistake to mark the type nodiscard, because there are plenty times when it's valid to ignore the type (consider many of the functions in <algorithm>, like std::copy()). I think it's more appropriate to mark the functions returning an iterator rather than the type itself.

I'm a little more sympathetic to the use than Aaron here, but I'm still at 'unmotivated' here. As he said, iterator I think is a poor candidate for nodiscard, as the iterator type itself is not the 'costly to ignore' part here, just the begin/end methods (and perhaps some of algorithms?). I can see some logic to having this in very limited situations, but I just don't see a motivating use case yet.

[cjdb]

Yeah, in retrospect, I agree (and may need to clean up a few iterator types now, grr).

clang/docs/ReleaseNotes.rst

 - Fixed mangling of nested dependent names such as ``T::a::b``, where ``T`` is a
   template parameter, to conform to the Itanium C++ ABI and be compatible with
   GCC. This breaks binary compatibility with code compiled with earlier versions
   of clang; use the ``-fclang-abi-compat=14`` option to get the old mangling.
 - Preprocessor character literals with a ``u8`` prefix are now correctly treated as
   unsigned character literals. This fixes `Issue 54886 <https://github.com/llvm/llvm-project/issues/54886>`_.
 - Stopped allowing constraints on non-template functions to be compliant with
   dcl.decl.general p4.
+- Added the attribute ``[[clang::discardable]]``, which cancels out ``[[nodiscard]]``.
+  This makes it possible for libraries to liberally use ``[[nodiscard]]`` inside
+  ``#pragma clang attribute``.
 
 C++20 Feature Support
 ^^^^^^^^^^^^^^^^^^^^^
 - Diagnose consteval and constexpr issues that happen at namespace scope. This
   partially addresses `Issue 51593 <https://github.com/llvm/llvm-project/issues/51593>`_.
 - No longer attempt to evaluate a consteval UDL function call at runtime when
   it is called through a template instantiation. This fixes
   `Issue 54578 <https://github.com/llvm/llvm-project/issues/54578>`_.

clang/include/clang/AST/Expr.h

public:
   /// always the type of the expr itself, if the return type is a reference
   /// type.
   QualType getCallReturnType(const ASTContext &Ctx) const;
 
   /// Returns the WarnUnusedResultAttr that is either declared on the called
   /// function, or its return type declaration.
   const Attr *getUnusedResultAttr(const ASTContext &Ctx) const;
 
+  /// Returns the DisableWarnUnusedResultAttr that is either declared on the
+  /// called function, or its return type declaration.
+  const Attr *getDisableUnusedResultAttr(const ASTContext &Ctx) const;
+
   /// Returns true if this call expression should warn on unused results.
   bool hasUnusedResultAttr(const ASTContext &Ctx) const {
     return getUnusedResultAttr(Ctx) != nullptr;
   }
 
   SourceLocation getRParenLoc() const { return RParenLoc; }
   void setRParenLoc(SourceLocation L) { RParenLoc = L; }
 

clang/include/clang/Basic/Attr.td

let AdditionalMembers = [{
     // Check whether this the C++11 nodiscard version, even in non C++11
     // spellings.
     bool IsCXX11NoDiscard() const {
       return this->getSemanticSpelling() == CXX11_nodiscard;
     }
   }];
 }
 
+def DisableWarnUnusedResult : InheritableAttr {
+  let Spellings = [Clang<"discardable", 0>];
+  let Subjects = SubjectList<[ObjCMethod, Enum, Record, FunctionLike, TypedefName]>;
+  let Documentation = [DisableWarnUnusedResultDocs];
+}
+
 def Weak : InheritableAttr {
   let Spellings = [GCC<"weak">];
   let Subjects = SubjectList<[Var, Function, CXXRecord]>;
   let Documentation = [WeakDocs];
   let SimpleHandler = 1;
 }
 
 def WeakImport : InheritableAttr {

clang/include/clang/Basic/AttrDocs.td

 migration for code using ``[[noreturn]]`` after including ``<stdnoreturn.h>``.
   }];
 }
 
 def NoMergeDocs : Documentation {
   let Category = DocCatStmt;
   let Content = [{
 If a statement is marked ``nomerge`` and contains call expressions, those call
-expressions inside the statement will not be merged during optimization. This 
+expressions inside the statement will not be merged during optimization. This
 attribute can be used to prevent the optimizer from obscuring the source
 location of certain calls. For example, it will prevent tail merging otherwise
 identical code sequences that raise an exception or terminate the program. Tail
 merging normally reduces the precision of source location information, making
 stack traces less useful for debugging. This attribute gives the user control
-over the tradeoff between code size and debug information precision. 
+over the tradeoff between code size and debug information precision.
 
-``nomerge`` attribute can also be used as function attribute to prevent all 
-calls to the specified function from merging. It has no effect on indirect 
+``nomerge`` attribute can also be used as function attribute to prevent all
+calls to the specified function from merging. It has no effect on indirect
 calls.
   }];
 }
 
 def NoInlineDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 This function attribute suppresses the inlining of a function at the call sites

 
 ``tvos``
   Apple's tvOS operating system. The minimum deployment target is specified by
   the ``-mtvos-version-min=*version*`` command-line argument.
 
 ``watchos``
   Apple's watchOS operating system. The minimum deployment target is specified by
   the ``-mwatchos-version-min=*version*`` command-line argument.
-  
 ``driverkit``
   Apple's DriverKit userspace kernel extensions. The minimum deployment target
   is specified as part of the triple.
 
 A declaration can typically be used even when deploying back to a platform
 version prior to when the declaration was introduced. When this happens, the
 declaration is `weakly linked
 <https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html>`_,
void usages() {
 
     S s;
     static_cast<marked_type>(s); // diagnoses
     (int)s; // diagnoses
   }
   }];
 }
 
+def DisableWarnUnusedResultDocs : Documentation {
+  let Category = DocCatFunction;
+  let Heading = "clang::discardable";
+  let Content = [{
+Although the default behaviour for C and C++ is to not diagnose ignored function
+calls, we can make this the default by using ``#pragma clang attribute
+push([[nodiscard]],  apply_to = function)``. When we have a function that can
+have its value discarded, we can use ``[[clang::discardable]]`` to indicate that
+the ``[[nodiscard]]`` attribute should be ignored.
+
+``[[clang::discardable]]`` can be placed anywhere ``[[nodiscard]]`` is allowed,
+but the presence of either is prioritised when it's applied to a callable.
+
+.. code-block c++
+  struct S1 {};
+  [[nodiscard, clang::discardable]] S1 f1();
+
+  struct [[nodiscard]] S2 {};
+  [[clang::discardable]] int f2();
+
+  struct [[clang::discardable]] S3 {};
+  [[nodiscard]] int f3();
+
+  int main() {
+    f1(); // no warning (cancels out)
+    f2(); // no warning (function attribute overrides type attribute)
+    f3(); // warno (function attribute overrides type attribute)
+  }
+  }];
+}
+
 def FallthroughDocs : Documentation {
   let Category = DocCatStmt;
   let Heading = "fallthrough";
   let Content = [{
 The ``fallthrough`` (or ``clang::fallthrough``) attribute is used
 to annotate intentional fall-through
 between switch labels. It can only be applied to a null statement placed at a
 point of execution between any statement and the next switch label. It is

 
 
 def NullabilityDocs : DocumentationCategory<"Nullability Attributes"> {
   let Content = [{
 Whether a particular pointer may be "null" is an important concern when working
 with pointers in the C family of languages. The various nullability attributes
 indicate whether a particular pointer can be null or not, which makes APIs more
 expressive and can help static analysis tools identify bugs involving null
-pointers. Clang supports several kinds of nullability attributes: the 
+pointers. Clang supports several kinds of nullability attributes: the
 ``nonnull`` and ``returns_nonnull`` attributes indicate which function or
 method parameters and result types can never be null, while nullability type
 qualifiers indicate which pointer types can be null (``_Nullable``) or cannot
 be null (``_Nonnull``).
 
 The nullability (type) qualifiers express whether a value of a given pointer
 type can be null (the ``_Nullable`` qualifier), doesn't have a defined meaning
 for null (the ``_Nonnull`` qualifier), or for which the purpose of null is
memory is not available rather than returning a null pointer:
 
   .. code-block:: c
 
     extern void * malloc (size_t size) __attribute__((returns_nonnull));
 
 The ``returns_nonnull`` attribute implies that returning a null pointer is
 undefined behavior, which the optimizer may take advantage of. The ``_Nonnull``
 type qualifier indicates that a pointer cannot be null in a more general manner
-(because it is part of the type system) and does not imply undefined behavior, 
+(because it is part of the type system) and does not imply undefined behavior,
 making it more widely applicable
 }];
 }
 
 def NoAliasDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 The ``noalias`` attribute indicates that the only memory accesses inside

 }];
 }
 
 def CFGuardDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 Code can indicate CFG checks are not wanted with the ``__declspec(guard(nocf))``
 attribute. This directs the compiler to not insert any CFG checks for the entire
-function. This approach is typically used only sparingly in specific situations 
-where the programmer has manually inserted "CFG-equivalent" protection. The 
-programmer knows that they are calling through some read-only function table 
-whose address is obtained through read-only memory references and for which the 
-index is masked to the function table limit. This approach may also be applied 
-to small wrapper functions that are not inlined and that do nothing more than 
-make a call through a function pointer. Since incorrect usage of this directive 
-can compromise the security of CFG, the programmer must be very careful using 
-the directive. Typically, this usage is limited to very small functions that 
+function. This approach is typically used only sparingly in specific situations
+where the programmer has manually inserted "CFG-equivalent" protection. The
+programmer knows that they are calling through some read-only function table
+whose address is obtained through read-only memory references and for which the
+index is masked to the function table limit. This approach may also be applied
+to small wrapper functions that are not inlined and that do nothing more than
+make a call through a function pointer. Since incorrect usage of this directive
+can compromise the security of CFG, the programmer must be very careful using
+the directive. Typically, this usage is limited to very small functions that
 only call one function.
 
 `Control Flow Guard documentation <https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata>`
 }];
 }
 
 def CUDADeviceBuiltinSurfaceTypeDocs : Documentation {
   let Category = DocCatType;

clang/lib/AST/Expr.cpp

 //===--- Expr.cpp - Expression AST Node Implementation --------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // This file implements the Expr class and subclasses.
 //
 //===----------------------------------------------------------------------===//
 
 #include "clang/AST/Expr.h"
 #include "clang/AST/APValue.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Attr.h"
+#include "clang/AST/Attrs.inc"
 #include "clang/AST/ComputeDependence.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/DependenceFlags.h"
 #include "clang/AST/EvaluatedExprVisitor.h"
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/IgnoreExpr.h"
if (const auto *A = TD->getDecl()->getAttr<WarnUnusedResultAttr>())
       return A;
 
   // Otherwise, see if the callee is marked nodiscard and return that attribute
   // instead.
   const Decl *D = getCalleeDecl();
   return D ? D->getAttr<WarnUnusedResultAttr>() : nullptr;
 }
 
+const Attr *CallExpr::getDisableUnusedResultAttr(const ASTContext &Ctx) const {
+  // Callees have the final say on whether or not their call is discardable, so
+  // we exit early if the callee has an opinion.
+
+  const Decl *D = getCalleeDecl();
+  const auto *CallResult =
+      D ? D->getAttr<DisableWarnUnusedResultAttr>() : nullptr;
+  if (CallResult != nullptr)
+    return CallResult;
+
+  bool CallIsNodiscard =
+      D ? D->getAttr<WarnUnusedResultAttr>() != nullptr : false;
+  if (CallIsNodiscard && CallResult == nullptr)
+    return nullptr;
+
+  // If the return type is a class or enum type that is marked discardable and
+  // the call isn't marked nodiscard, return the type attribute.
+  if (const TagDecl *TD = getCallReturnType(Ctx)->getAsTagDecl())
+    if (const auto *A = TD->getAttr<DisableWarnUnusedResultAttr>())
+      return A;
+
+  for (const auto *TD = getCallReturnType(Ctx)->getAs<TypedefType>(); TD;
+       TD = TD->desugar()->getAs<TypedefType>())
+    if (const auto *A = TD->getDecl()->getAttr<DisableWarnUnusedResultAttr>())
+      return A;
+
+  return nullptr;
+}
+
 SourceLocation CallExpr::getBeginLoc() const {
   if (isa<CXXOperatorCallExpr>(this))
     return cast<CXXOperatorCallExpr>(this)->getBeginLoc();
 
   SourceLocation begin = getCallee()->getBeginLoc();
   if (begin.isInvalid() && getNumArgs() > 0 && getArg(0))
     begin = getArg(0)->getBeginLoc();
   return begin;
if (Ctx.getLangOpts().ObjCAutoRefCount &&
         ME->getMethodFamily() == OMF_init) {
       WarnE = this;
       Loc = getExprLoc();
       R1 = ME->getSourceRange();
       return true;
     }
 
     if (const ObjCMethodDecl *MD = ME->getMethodDecl())
-      if (MD->hasAttr<WarnUnusedResultAttr>()) {
+      if (MD->hasAttr<WarnUnusedResultAttr>() &&
+          !MD->hasAttr<DisableWarnUnusedResultAttr>()) {
         WarnE = this;
         Loc = getExprLoc();
         return true;
       }
 
     return false;
   }
 

clang/lib/Sema/SemaDeclAttr.cpp

if ((!AL.isGNUAttribute() &&
     S.Diag(AL.getLoc(), diag::warn_unused_result_typedef_unsupported_spelling)
         << AL.isGNUScope();
     return;
   }
 
   D->addAttr(::new (S.Context) WarnUnusedResultAttr(S.Context, AL, Str));
 }
 
+static void handleDisableWarnUnusedResult(Sema &S, Decl *D,
+                                          const ParsedAttr &AL) {
+  if (D->getFunctionType() &&
+      D->getFunctionType()->getReturnType()->isVoidType() &&
+      !isa<CXXConstructorDecl>(D)) {
+    S.Diag(AL.getLoc(), diag::warn_attribute_void_function_method) << AL << 0;
+    return;
+  }
+  if (const auto *MD = dyn_cast<ObjCMethodDecl>(D))
+    if (MD->getReturnType()->isVoidType()) {
+      S.Diag(AL.getLoc(), diag::warn_attribute_void_function_method) << AL << 1;
+      return;
+    }
+
+  if (AL.isStandardAttributeSyntax() && !AL.getScopeName()) {
+    // The standard attribute cannot be applied to variable declarations such
+    // as a function pointer.
+    if (isa<VarDecl>(D))
+      S.Diag(AL.getLoc(), diag::warn_attribute_wrong_decl_type_str)
+          << AL << "functions, classes, or enumerations";
+  }
+
+  if ((!AL.isGNUAttribute() &&
+       !(AL.isStandardAttributeSyntax() && AL.isClangScope())) &&
+      isa<TypedefNameDecl>(D)) {
+    S.Diag(AL.getLoc(), diag::warn_unused_result_typedef_unsupported_spelling)
+        << AL.isGNUScope();
+    return;
+  }
+
+  D->addAttr(::new (S.Context) DisableWarnUnusedResultAttr(S.Context, AL));
+}
+
 static void handleWeakImportAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   // weak_import only applies to variable & function declarations.
   bool isDef = false;
   if (!D->canBeWeakImported(isDef)) {
     if (isDef)
       S.Diag(AL.getLoc(), diag::warn_attribute_invalid_on_definition)
         << "weak_import";
     else if (isa<ObjCPropertyDecl>(D) || isa<ObjCMethodDecl>(D) ||
case ParsedAttr::AT_Visibility:
     handleVisibilityAttr(S, D, AL, false);
     break;
   case ParsedAttr::AT_TypeVisibility:
     handleVisibilityAttr(S, D, AL, true);
     break;
   case ParsedAttr::AT_WarnUnusedResult:
     handleWarnUnusedResult(S, D, AL);
     break;
+  case ParsedAttr::AT_DisableWarnUnusedResult:
+    handleDisableWarnUnusedResult(S, D, AL);
+    break;
   case ParsedAttr::AT_WeakRef:
     handleWeakRefAttr(S, D, AL);
     break;
   case ParsedAttr::AT_WeakImport:
     handleWeakImportAttr(S, D, AL);
     break;
   case ParsedAttr::AT_TransparentUnion:
     handleTransparentUnionAttr(S, D, AL);

clang/lib/Sema/SemaStmt.cpp

if (const auto *Cast = dyn_cast<CastExpr>(E))
     if (Cast->getCastKind() == CK_NoOp ||
         Cast->getCastKind() == CK_ConstructorConversion)
       E = Cast->getSubExpr()->IgnoreImpCasts();
 
   if (const CallExpr *CE = dyn_cast<CallExpr>(E)) {
     if (E->getType()->isVoidType())
       return;
 
-    if (DiagnoseNoDiscard(*this, cast_or_null<WarnUnusedResultAttr>(
-                                     CE->getUnusedResultAttr(Context)),
+    if (CE->getDisableUnusedResultAttr(Context))
+      return;
+
+    if (DiagnoseNoDiscard(*this,
+                          cast_or_null<WarnUnusedResultAttr>(
                           Loc, R1, R2, /*isCtor=*/false))
       return;
 
     // If the callee has attribute pure, const, or warn_unused_result, warn with
     // a more specific message to make it clear what is happening. If the call
     // is written in a macro body, only warn if it has the warn_unused_result
     // attribute.
     if (const Decl *FD = CE->getCalleeDecl()) {
       if (ShouldSuppress)
         return;
       if (FD->hasAttr<PureAttr>()) {
         Diag(Loc, diag::warn_unused_call) << R1 << R2 << "pure";
         return;
       }
       if (FD->hasAttr<ConstAttr>()) {
         Diag(Loc, diag::warn_unused_call) << R1 << R2 << "const";
         return;
       }
     }
   } else if (const auto *CE = dyn_cast<CXXConstructExpr>(E)) {
     if (const CXXConstructorDecl *Ctor = CE->getConstructor()) {
+      const auto *D = Ctor->getAttr<DisableWarnUnusedResultAttr>();
+      D = D ? D : Ctor->getParent()->getAttr<DisableWarnUnusedResultAttr>();
+      if (D)
+        return;
+
       const auto *A = Ctor->getAttr<WarnUnusedResultAttr>();
       A = A ? A : Ctor->getParent()->getAttr<WarnUnusedResultAttr>();
       if (DiagnoseNoDiscard(*this, A, Loc, R1, R2, /*isCtor=*/true))
         return;
     }
   } else if (const auto *ILE = dyn_cast<InitListExpr>(E)) {
     if (const TagDecl *TD = ILE->getType()->getAsTagDecl()) {
+      if (TD->getAttr<DisableWarnUnusedResultAttr>())
+        return;
 
       if (DiagnoseNoDiscard(*this, TD->getAttr<WarnUnusedResultAttr>(), Loc, R1,
                             R2, /*isCtor=*/false))
         return;
     }
   } else if (ShouldSuppress)
     return;
 
   E = WarnExpr;
   if (const ObjCMessageExpr *ME = dyn_cast<ObjCMessageExpr>(E)) {
     if (getLangOpts().ObjCAutoRefCount && ME->isDelegateInitCall()) {
       Diag(Loc, diag::err_arc_unused_init_message) << R1;
       return;
     }
     const ObjCMethodDecl *MD = ME->getMethodDecl();
     if (MD) {
+      if (MD->getAttr<DisableWarnUnusedResultAttr>())
+        return;
       if (DiagnoseNoDiscard(*this, MD->getAttr<WarnUnusedResultAttr>(), Loc, R1,
                             R2, /*isCtor=*/false))
         return;
     }
   } else if (const PseudoObjectExpr *POE = dyn_cast<PseudoObjectExpr>(E)) {
     const Expr *Source = POE->getSyntacticForm();
     // Handle the actually selected call of an OpenMP specialized call.
     if (LangOpts.OpenMP && isa<CallExpr>(Source) &&

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

 // CHECK-NEXT: ConsumableSetOnRead (SubjectMatchRule_record)
 // CHECK-NEXT: Convergent (SubjectMatchRule_function)
 // CHECK-NEXT: DLLExport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
 // CHECK-NEXT: DLLImport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
 // CHECK-NEXT: Destructor (SubjectMatchRule_function)
 // CHECK-NEXT: DiagnoseAsBuiltin (SubjectMatchRule_function)
 // CHECK-NEXT: DisableSanitizerInstrumentation (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_variable_is_global)
 // CHECK-NEXT: DisableTailCalls (SubjectMatchRule_function, SubjectMatchRule_objc_method)
+// CHECK-NEXT: DisableWarnUnusedResult (SubjectMatchRule_objc_method, SubjectMatchRule_enum, SubjectMatchRule_record, SubjectMatchRule_hasType_functionType, SubjectMatchRule_type_alias)
 // CHECK-NEXT: EnableIf (SubjectMatchRule_function)
 // CHECK-NEXT: EnforceTCB (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: EnforceTCBLeaf (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: EnumExtensibility (SubjectMatchRule_enum)
 // CHECK-NEXT: Error (SubjectMatchRule_function)
 // CHECK-NEXT: ExcludeFromExplicitInstantiation (SubjectMatchRule_variable, SubjectMatchRule_function, SubjectMatchRule_record)
 // CHECK-NEXT: ExternalSourceSymbol ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_implementation, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: FlagEnum (SubjectMatchRule_enum)

clang/test/SemaCXX/discardable.cpp

+// RUN: %clang_cc1 -fsyntax-only -Wunknown-attributes -verify -std=c++17 %s
+
+[[clang::discardable]] int without_nodiscard();
+
+[[nodiscard, clang::discardable]] int no_warn_fundamental();
+
+struct naked {};
+[[nodiscard, clang::discardable]] naked no_warn_class_type();
+[[nodiscard, clang::discardable]] naked* no_warn_pointer();
+[[nodiscard, clang::discardable]] naked& no_warn_reference();
+
+struct [[nodiscard]] nodiscard_type {};
+[[clang::discardable]] nodiscard_type no_warn_function_override();
+
+struct [[clang::discardable]] discardable_type {};
+discardable_type no_warn_discardable_type();
+[[nodiscard]] discardable_type warns_function_override();
+
+struct [[nodiscard, clang::discardable]] discardable_type2 {};
+discardable_type2 no_warn_discardable_type2();
+
+struct discardable_members {
+  [[nodiscard, clang::discardable]] discardable_members(int);
+  [[nodiscard, clang::discardable]] int f() const;
+};
+
+void test_expression_statements() {
+  without_nodiscard();
+
+  no_warn_fundamental();
+
+  no_warn_class_type();
+  no_warn_pointer();
+  no_warn_reference();
+
+  no_warn_function_override();
+
+  no_warn_discardable_type();
+  warns_function_override(); // expected-warning{{ignoring return value}}
+
+  no_warn_discardable_type2();
+
+  discardable_members(0);
+  discardable_members(0).f();
+}