[AST] Add msvc-specific C++11 attributes

[RIscRIpt]

Summary

• 'msvc::no_tls_guard', first appeared in MSVC toolchain 14.25.28610
• 'msvc::known_semantics', first appeared in MSVC toolchain 14.27.29110
• 'msvc::noop_dtor', first appeared in MSVC toolchain 14.28.29333
• 'msvc::constexpr', first appeared in MSVC toolchain 14.33.31629

Closes #57696

[aaron.ballman]

Thank you for the patch! I'm wondering what the goal is for these changes. We don't typically add attributes to Clang that don't have any effect unless there's a very compelling reason to do so. Are you intending to add semantics for these attributes in follow-up patches?

[RIscRIpt]

In D133853#3792518, @aaron.ballman wrote:

I'm wondering what the goal is for these changes. ... Are you intending to add semantics for these attributes in follow-up patches?

To be honest, I wasn't planning to do any of follow-up patches. I made a patch for internal usage at my job, and decided to submit it upstream.
The main reason I (we) need this patch is that we need to be able to parse MSVC-specific code (in the current case - detect constexpr functions). Since Visual Studio 17.3 (MSVC 14.33.31629), Microsoft's STL library added [[msvc::constexpr]] attribute, which is not documented yet, but makes a function to act like a constexpr function: see this godbolt sample (i.e. forbids non-constexpr statements inside).

To make the patch complete, I decided to browse previous Microsoft's STL versions and see which vendor specific (msvc::) attributes they added previously; in this patch I added all attributes I was able to find.

We don't typically add attributes to Clang that don't have any effect unless there's a very compelling reason to do so.

Theoretically, I could re-submit (or adjust this) patch, which would add support for [[msvc::constexpr]] attribute with semantic meaning of constexpr for functions (for code parsed with -fms-extensions flag). Regarding other attributes - unfortunately they are either poorly documented, or not documented at all, so I can drop commits for these attributes.

*Edit:* Please, let me know how we can proceed - either I abandon the patch; or add support only for [[msvc::constexpr]], or any other way of proceeding further?

[aaron.ballman]

In D133853#3793284, @RIscRIpt wrote:

In D133853#3792518, @aaron.ballman wrote:

I'm wondering what the goal is for these changes. ... Are you intending to add semantics for these attributes in follow-up patches?

To be honest, I wasn't planning to do any of follow-up patches. I made a patch for internal usage at my job, and decided to submit it upstream.
The main reason I (we) need this patch is that we need to be able to parse MSVC-specific code (in the current case - detect constexpr functions). Since Visual Studio 17.3 (MSVC 14.33.31629), Microsoft's STL library added [[msvc::constexpr]] attribute, which is not documented yet, but makes a function to act like a constexpr function: see this godbolt sample (i.e. forbids non-constexpr statements inside).

To make the patch complete, I decided to browse previous Microsoft's STL versions and see which vendor specific (msvc::) attributes they added previously; in this patch I added all attributes I was able to find.

We don't typically add attributes to Clang that don't have any effect unless there's a very compelling reason to do so.

Theoretically, I could re-submit (or adjust this) patch, which would add support for [[msvc::constexpr]] attribute with semantic meaning of constexpr for functions (for code parsed with -fms-extensions flag). Regarding other attributes - unfortunately they are either poorly documented, or not documented at all, so I can drop commits for these attributes.

*Edit:* Please, let me know how we can proceed - either I abandon the patch; or add support only for [[msvc::constexpr]], or any other way of proceeding further?

Thanks for the information! Roping in @erichkeane as attribute code owner to make sure he's on board with the idea, but my suggestion is to only support [[msvc::constexpr]] with the semantic meaning of constexpr. It's a good question as to whether we want to support that only when passing -fms-extensions or not (it seems like a generally useful attribute); we don't do the same for GNU attributes, but maybe we don't want to follow that pattern? This will be the first attribute we add with the msvc vendor namespace.

If you find there's a good reason to upstream the other ones, we can certainly consider it. FWIW, one Microsoft-specific attribute I know people have been asking about is [[msvc::no_unique_address]]. See https://github.com/llvm/llvm-project/issues/49358 for more details. Not suggesting you're on the hook for that or anything, just pointing it out in case you wanted to work on that one at some point.

[erichkeane]

In D133853#3795579, @aaron.ballman wrote:

In D133853#3793284, @RIscRIpt wrote:

In D133853#3792518, @aaron.ballman wrote:

I'm wondering what the goal is for these changes. ... Are you intending to add semantics for these attributes in follow-up patches?

To be honest, I wasn't planning to do any of follow-up patches. I made a patch for internal usage at my job, and decided to submit it upstream.
The main reason I (we) need this patch is that we need to be able to parse MSVC-specific code (in the current case - detect constexpr functions). Since Visual Studio 17.3 (MSVC 14.33.31629), Microsoft's STL library added [[msvc::constexpr]] attribute, which is not documented yet, but makes a function to act like a constexpr function: see this godbolt sample (i.e. forbids non-constexpr statements inside).

To make the patch complete, I decided to browse previous Microsoft's STL versions and see which vendor specific (msvc::) attributes they added previously; in this patch I added all attributes I was able to find.

We don't typically add attributes to Clang that don't have any effect unless there's a very compelling reason to do so.

Theoretically, I could re-submit (or adjust this) patch, which would add support for [[msvc::constexpr]] attribute with semantic meaning of constexpr for functions (for code parsed with -fms-extensions flag). Regarding other attributes - unfortunately they are either poorly documented, or not documented at all, so I can drop commits for these attributes.

*Edit:* Please, let me know how we can proceed - either I abandon the patch; or add support only for [[msvc::constexpr]], or any other way of proceeding further?

Thanks for the information! Roping in @erichkeane as attribute code owner to make sure he's on board with the idea, but my suggestion is to only support [[msvc::constexpr]] with the semantic meaning of constexpr. It's a good question as to whether we want to support that only when passing -fms-extensions or not (it seems like a generally useful attribute); we don't do the same for GNU attributes, but maybe we don't want to follow that pattern? This will be the first attribute we add with the msvc vendor namespace.

If you find there's a good reason to upstream the other ones, we can certainly consider it. FWIW, one Microsoft-specific attribute I know people have been asking about is [[msvc::no_unique_address]]. See https://github.com/llvm/llvm-project/issues/49358 for more details. Not suggesting you're on the hook for that or anything, just pointing it out in case you wanted to work on that one at some point.

I agree with Aaron here, there isn't much value in the "do nothing" attributes, I believe the 'unknown attribute' warning for them is superior to an ignored attribute.

A functional msvc::constexpr would be acceptable, however, I'm having a difficult time figuring out the purpose of it, it seems like it is just a 'constepr keyword' replacement?

clang/lib/Sema/SemaStmtAttr.cpp

296

Typically we try to do the ::Create function that is generated for attributes, rather than placement new. I realize we are consistently inconsistent...

[RIscRIpt]

In D133853#3795579, @aaron.ballman wrote:

but my suggestion is to only support [[msvc::constexpr]] with the semantic meaning of constexpr

Sounds good to me.

It's a good question as to whether we want to support that only when passing -fms-extensions or not (it seems like a generally useful attribute); we don't do the same for GNU attributes, but maybe we don't want to follow that pattern? This will be the first attribute we add with the msvc vendor namespace.

IMO, this attribute is a clearly Microsoft's extension, thus it should be available only when -fms-extensions are enabled.

If you find there's a good reason to upstream the other ones, we can certainly consider it.

I don't see any good reason for other attributes to be added.

FWIW, one Microsoft-specific attribute I know people have been asking about is [[msvc::no_unique_address]]

Thanks for letting me know.

The current patch is my first attempt to contribute to LLVM; I am afraid it would take me some effort to implement semantics of [[msvc::no_unique_address]], so I'd like to focus only on [[msvc::constexpr]] in current patch.

In D133853#3795598, @erichkeane wrote:

A functional msvc::constexpr would be acceptable, however, I'm having a difficult time figuring out the purpose of it, it seems like it is just a 'constexpr keyword' replacement?

I don't know how it works internally, but judging by its behavior - yes it's a constexpr replacement with some extended functionality (my guess is that they wanted to do some constexpr magic, and staying compatible with the standard at the same time), and there's a few information available online:

Merged an MSVC-specific attribute, allowing the compiler to improve its handling of constexpr dynamic allocation and constexpr unique_ptr. [1]

// Determine if we should use [[msvc::constexpr]] to allow for "extended constexpr" in Visual C++. [2]

Browsing MSVC 14.33.31629 include headers I can see that this attribute is mostly used in operator new functions: either as a decorator of the function or the return statement.

I guess the best way to make this attribute compatible with MSVC would be ask someone at Microsoft, but I'm not sure who to reach out.

Meanwhile I'll adjust current patch to focus only [[msvc::constexpr]] attribute.

I believe the 'unknown attribute' warning for them is superior to an ignored attribute.

By the way, I'd like to take opportunity and ask what do you think of adding clang-specific compiler flag, which would add all unknown attributes to the AST in a string form (e.g. [[attr1]] -> AST::UnknownAttr{"attr1"}? Would you be interested in such patch?

[1] https://github.com/microsoft/STL/wiki/Changelog

[2] 14.33.31629\include\vcruntime.h

[aaron.ballman]

In D133853#3797598, @RIscRIpt wrote:

In D133853#3795579, @aaron.ballman wrote:

FWIW, one Microsoft-specific attribute I know people have been asking about is [[msvc::no_unique_address]]

Thanks for letting me know.

The current patch is my first attempt to contribute to LLVM; I am afraid it would take me some effort to implement semantics of [[msvc::no_unique_address]], so I'd like to focus only on [[msvc::constexpr]] in current patch.

No worries, thanks for at least thinking about it!

In D133853#3795598, @erichkeane wrote:

A functional msvc::constexpr would be acceptable, however, I'm having a difficult time figuring out the purpose of it, it seems like it is just a 'constexpr keyword' replacement?

It's a conforming extension in older language modes like C++98, where we couldn't steal the constexpr keyword because it's not reserved, which is one benefit to it. Does MSVC support this as far back as C++98?

I believe the 'unknown attribute' warning for them is superior to an ignored attribute.

By the way, I'd like to take opportunity and ask what do you think of adding clang-specific compiler flag, which would add all unknown attributes to the AST in a string form (e.g. [[attr1]] -> AST::UnknownAttr{"attr1"}? Would you be interested in such patch?

We would be, but it's tricky. The idea we've had in mind for a while is to add an UnknownAttr type which wraps information the parser was able to scrape together. Things like the vendor namespace and attribute name are quite easy to keep around and would be a good initial offering. However, attribute arguments are going to be more difficult to handle because they can be arbitrary token soup rather than code which forms a valid AST node. e.g., [[foo("oh no!")]] isn't bad but [[foo(we don't even know what this is)]] and we can't even necessarily save off tokens for it because it could contain punctuation which isn't a valid token by itself, like ' without a terminating single quote). So the initial offering could save the source range of the parens for the arguments (this way you can at least get back to the text in the source code if you need to), but I don't know that we have a good idea how to handle exposing the argument information.

[h-vetinari]

In D133853#3797598, @RIscRIpt wrote:

I am afraid it would take me some effort to implement semantics of [[msvc::no_unique_address]], so I'd like to focus only on [[msvc::constexpr]] in current patch.

Just for context, [[msvc::no_unique_address]] is 100% like the standardized [[no_unique_address]], but MSFT was... exceedingly cautious... about introducing this, as - even for an explicitly opt-in new feature - someone might have compiled code containing [[no_unique_address]] at a time when it was a no-op in their compiler (as an unknown attribute), and changing the semantics after the fact would have violated their very strict compatibility guarantees.

I assume the reasoning behind [[msvc::constexpr]] to be along the same lines.

[RIscRIpt]

In D133853#3799344, @aaron.ballman wrote:

It's a conforming extension in older language modes like C++98, where we couldn't steal the constexpr keyword because it's not reserved, which is one benefit to it. Does MSVC support this as far back as C++98?

Tbh, I cannot understand your question in relation to your statement, and where did you get that statement from 🙂

Does MSVC support this as far back as C++98?

I don't know. AFAIK - no.

@h-vetinari thanks for your input.

I'll try to update this patch as per our discussion:

1. [[msvc::constexpr]] handle like constexpr for functions with -fms-extensions (according to MSVC error message: C7687: [[msvc::constexpr]] may only be applied to statements and functions); I won't implement semantic meaning for statements, as I am now aware of it and there's no constexpr effect on statements.
2. Possibly take a look at [[msvc::no_unique_address]]

[aaron.ballman]

In D133853#3808669, @RIscRIpt wrote:

In D133853#3799344, @aaron.ballman wrote:

It's a conforming extension in older language modes like C++98, where we couldn't steal the constexpr keyword because it's not reserved, which is one benefit to it. Does MSVC support this as far back as C++98?

Tbh, I cannot understand your question in relation to your statement, and where did you get that statement from 🙂

Ah, I forgot that MSVC's /std: flag only goes as far back as C++14. I was wondering two things: 1) does MSVC support [[]] attributes in C++ modes earlier than C++11 (moot, there is no C++ earlier than 14 for MSVC) and 2) does MSVC support [[msvc::constexpr]] in C++ modes earlier than C++11 (also moot). If the answer to both of those questions was "yes", then I'd understand why this attribute exists (it would be a conforming extension in those language modes, where they could not expose constexpr as a keyword). Now I'm wondering why the attribute exists at all. If it's functionally equivalent to constexpr as a keyword, what are the use cases for the attribute?

[h-vetinari]

Now I'm wondering why the attribute exists at all. If it's functionally equivalent to constexpr as a keyword, what are the use cases for the attribute?

I'm guessing something to do with ABI-compatibility with artefacts produced by their older compilers (though I have no idea what scenario they have come up with that would break). It's also for a very recent version (17.3, the last non-preview release as of writing), and I cannot find documentation for it.

Though while searching for it, I stumbled over https://reviews.llvm.org/D110485, which relates to [[no_unique_address]] & how it's incompatible to use it for clang on windows if MSVC doesn't.

[RIscRIpt]

I am new to arc, I tried arc diff --edit --verbatim as it's said in the docs, but it still created a new revision: https://reviews.llvm.org/D134458

clang/lib/Sema/SemaStmtAttr.cpp

296

I could address this, but could you please provide an example? Because all handle functions in this file use placement new.

[RIscRIpt]

Closing in favor of https://reviews.llvm.org/D134475

[cpplearner]

In D133853#3808674, @aaron.ballman wrote:

Now I'm wondering why the attribute exists at all. If it's functionally equivalent to constexpr as a keyword, what are the use cases for the attribute?

It appears that [[msvc::constexpr]] does not make a function constexpr, but if [[msvc::constexpr]] is used in a function definition and in a call to that function, then the annotated function call can be evaluated during constant evaluation: https://godbolt.org/z/3MPTsz6Yn

Apparently this is used to implement constexpr std::construct_at, which needs to call placement operator new, but the latter is not constexpr.

clang/include/clang/Basic/Attr.td

def Pointer : InheritableAttr {
   let Subjects = SubjectList<[Struct]>;
   let Args = [TypeArgument<"DerefType", /*opt=*/1>];
   let Documentation = [LifetimePointerDocs];
 }
 def : MutualExclusions<[Owner, Pointer]>;
 
 // Microsoft-related attributes
 
+def MSNoTlsGuard : InheritableAttr {
+  let LangOpts = [MicrosoftExt];
+  let Spellings = [CXX11<"msvc", "no_tls_guard">];
+  let Subjects = SubjectList<[Var], ErrorDiag>;
+  let Documentation = [MSNoTlsGuardDocs];
+  let SimpleHandler = 1;
+}
+
+def MSKnownSemantics : TypeAttr {
+  let LangOpts = [MicrosoftExt];
+  let Spellings = [CXX11<"msvc", "known_semantics">];
+  let Documentation = [MSKnownSemanticsDocs];
+  let SimpleHandler = 1;
+}
+
+def MSNoopDtor : InheritableAttr {
+  let LangOpts = [MicrosoftExt];
+  let Spellings = [CXX11<"msvc", "noop_dtor">];
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+  let Documentation = [MSNoopDtorDocs];
+  let SimpleHandler = 1;
+}
+
+def MSConstexpr : DeclOrStmtAttr {
+  let LangOpts = [MicrosoftExt];
+  let Spellings = [CXX11<"msvc", "constexpr">];
+  let Subjects = SubjectList<[Function, Stmt], ErrorDiag,
+                             "functions and statements">;
+  let Documentation = [MSConstexprDocs];
+  let SimpleHandler = 1;
+}
+
 def MSNoVTable : InheritableAttr, TargetSpecificAttr<TargetMicrosoftCXXABI> {
   let Spellings = [Declspec<"novtable">];
   let Subjects = SubjectList<[CXXRecord]>;
   let Documentation = [MSNoVTableDocs];
   let SimpleHandler = 1;
 }
 
 def : IgnoredAttr {

clang/include/clang/Basic/AttrDocs.td

 .. code-block:: c++
 
   struct __multiple_inheritance S; // error: inheritance model does not match definition
   int S::*i;
   struct S {};
 }];
 }
 
+def MSNoTlsGuardDocs : Documentation {
+  let Category = DocCatVariable;
+  let Content = [{
+This attribute can be added to a TLS variable to disable initialization
+test check in threads which existed before DLL was loaded.
+It applies behavior of '/Zc:tlsGuards-' flag to the variable.
+Has no effect on clang.
+  }];
+}
+
+def MSKnownSemanticsDocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+This attribute tells MSVC compiler that the type trait specialization
+have the standard-mandated semantics.
+Has no effect on clang.
+  }];
+}
+
+def MSNoopDtorDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+This attribute tells MSVC compiler that the destructor have no effects.
+Has no effect on clang.
+  }];
+}
+
+def MSConstexprDocs : Documentation {
+  let Category = DocCatStmt;
+  let Content = [{
+This attribute allows MSVC compiler to use "externed constexpr".
+Has no effect on clang.
+  }];
+}
+
 def MSNoVTableDocs : Documentation {
   let Category = DocCatDecl;
   let Content = [{
 This attribute can be added to a class declaration or definition to signal to
 the compiler that constructors and destructors will not reference the virtual
 function table. It is only supported when using the Microsoft C++ ABI.
   }];
 }

clang/lib/AST/TypePrinter.cpp

#include "clang/Basic/AttrList.inc"
   case attr::ObjCOwnership:
   case attr::Ptr32:
   case attr::Ptr64:
   case attr::SPtr:
   case attr::UPtr:
   case attr::AddressSpace:
   case attr::CmseNSCall:
   case attr::AnnotateType:
+  case attr::MSKnownSemantics:
     llvm_unreachable("This attribute should have been handled already");
 
   case attr::NSReturnsRetained:
     OS << "ns_returns_retained";
     break;
 
   // FIXME: When Sema learns to form this AttributedType, avoid printing the
   // attribute again in printFunctionProtoAfter.

clang/lib/Sema/SemaStmtAttr.cpp

static Attr *handleUnlikely(Sema &S, Stmt *St, const ParsedAttr &A,
                             SourceRange Range) {
 
   if (!S.getLangOpts().CPlusPlus20 && A.isCXX11Attribute() && !A.getScopeName())
     S.Diag(A.getLoc(), diag::ext_cxx20_attr) << A << Range;
 
   return ::new (S.Context) UnlikelyAttr(S.Context, A);
 }
 
+static Attr *handleMSConstexpr(Sema &S, Stmt *St, const ParsedAttr &A,
+                               SourceRange Range) {
+  // Validation is in Sema::ActOnAttributedStmt().
+  return ::new (S.Context) MSConstexprAttr(S.Context, A);
+}
+
 #define WANT_STMT_MERGE_LOGIC
 #include "clang/Sema/AttrParsedAttrImpl.inc"
 #undef WANT_STMT_MERGE_LOGIC
 
 static void
 CheckForIncompatibleAttributes(Sema &S,
                                const SmallVectorImpl<const Attr *> &Attrs) {
   // The vast majority of attributed statements will only have one attribute
static Attr *ProcessStmtAttribute(Sema &S, Stmt *St, const ParsedAttr &A,
   case ParsedAttr::AT_NoInline:
     return handleNoInlineAttr(S, St, A, Range);
   case ParsedAttr::AT_MustTail:
     return handleMustTailAttr(S, St, A, Range);
   case ParsedAttr::AT_Likely:
     return handleLikely(S, St, A, Range);
   case ParsedAttr::AT_Unlikely:
     return handleUnlikely(S, St, A, Range);
+  case ParsedAttr::AT_MSConstexpr:
+    return handleMSConstexpr(S, St, A, Range);
   default:
     // N.B., ClangAttrEmitter.cpp emits a diagnostic helper that ensures a
     // declaration attribute is not written on a statement, but this code is
     // needed for attributes in Attr.td that do not list any subjects.
     S.Diag(A.getRange().getBegin(), diag::err_decl_attribute_invalid_on_stmt)
         << A << St->getBeginLoc();
     return nullptr;
   }

clang/test/AST/msvc-attrs.cpp

+// RUN: %clang_cc1 -fms-extensions -std=c++20 -DMSX -ast-dump %s | FileCheck %s
+// RUN: not %clang_cc1 -Werror=ignored-attributes -ast-dump %s 2>&1 | grep "8 errors generated"
+
+// CHECK: VarDecl 0x{{[0-9a-f]+}} <{{.*}}:[[@LINE+3]]:24, col:47> col:47 no_tls_guard_var
+// CHECK-NEXT: MSNoTlsGuardAttr 0x{{[0-9a-f]+}} <col:3, col:9>
+// CHECK-NEXT: ThreadAttr 0x{{[0-9a-f]+}} <col:35>
+[[msvc::no_tls_guard]] __declspec(thread) int no_tls_guard_var;
+
+// CHECK: MSKnownSemanticsAttr 0x{{[0-9a-f]+}} <col:10, col:16>
+// CHECK-NEXT: CXXRecordDecl 0x{{[0-9a-f]+}} <col:1, col:34> col:34
+struct [[msvc::known_semantics]] Struct {};
+
+// CHECK: TypeAliasDecl 0x{{[0-9a-f]+}} <line:[[@LINE+3]]:1, col:39> col:7 Int 'int'
+// CHECK-NEXT: BuiltinType 0x{{[0-9a-f]+}} 'int'
+// CHECK-NEXT: MSKnownSemanticsAttr 0x{{[0-9a-f]+}} <col:13, col:19>
+using Int [[msvc::known_semantics]] = int;
+
+struct Dtor {
+  // CHECK: CXXDestructorDecl 0x{{[0-9a-f]+}} <line:[[@LINE+3]]:23, col:32> col:23 ~Dtor 'void () noexcept'
+  // CHECK-NEXT: CompoundStmt 0x{{[0-9a-f]+}} <col:31, col:32>
+  // CHECK-NEXT: MSNoopDtorAttr 0x{{[0-9a-f]+}} <col:5, col:11>
+  [[msvc::noop_dtor]] ~Dtor() {}
+};
+
+// CHECK: FunctionDecl 0x{{[0-9a-f]+}} <line:[[@LINE+2]]:21, col:61> col:27 New1 'void *(void *)'
+// CHECK: MSConstexprAttr 0x{{[0-9a-f]+}} <col:3, col:9>
+[[msvc::constexpr]] void *New1(void *where) { return where; }
+
+// CHECK: FunctionDecl {{.*}} <line:[[@LINE+4]]:1, line:[[@LINE+6]]:1> line:[[@LINE+4]]:17 constexpr New2
+// CHECK-NEXT: CompoundStmt
+// CHECK-NEXT: AttributedStmt
+// CHECK-NEXT: MSConstexprAttr
+constexpr char *New2() {
+  [[msvc::constexpr]] return ::new char[1];
+}

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

 // CHECK-NEXT: IFunc (SubjectMatchRule_function)
 // CHECK-NEXT: InitPriority (SubjectMatchRule_variable)
 // CHECK-NEXT: InternalLinkage (SubjectMatchRule_variable, SubjectMatchRule_function, SubjectMatchRule_record)
 // CHECK-NEXT: LTOVisibilityPublic (SubjectMatchRule_record)
 // CHECK-NEXT: Leaf (SubjectMatchRule_function)
 // CHECK-NEXT: LoaderUninitialized (SubjectMatchRule_variable_is_global)
 // CHECK-NEXT: Lockable (SubjectMatchRule_record)
 // CHECK-NEXT: MIGServerRoutine (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_block)
+// CHECK-NEXT: MSConstexpr (SubjectMatchRule_function)
+// CHECK-NEXT: MSNoTlsGuard (SubjectMatchRule_variable)
+// CHECK-NEXT: MSNoopDtor (SubjectMatchRule_function)
 // CHECK-NEXT: MSStruct (SubjectMatchRule_record)
 // CHECK-NEXT: MaybeUndef (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: MicroMips (SubjectMatchRule_function)
 // CHECK-NEXT: MinSize (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: MinVectorWidth (SubjectMatchRule_function)
 // CHECK-NEXT: Mips16 (SubjectMatchRule_function)
 // CHECK-NEXT: MipsLongCall (SubjectMatchRule_function)
 // CHECK-NEXT: MipsShortCall (SubjectMatchRule_function)