[PATCH] Improved handling of the naked attribute for MSVC compatibility

[Reid Kleckner]

Cool!  There's two instances of trailing whitespace you'll want to fix.

-  if (!isa<FunctionDecl>(D)) {
+  // Microsoft mode expects the naked attribute to only be applied to a
+  // function definition, or else it causes an error.  In non-Microsoft mode,
+  // the attribute is allowed to be attached to a function definition or is
+  // otherwise warned about.
+  //
+  // Because the attribute is handled before the function body is parsed, try
+  // to use the Declarator to determine whether this is a function definition
+  // or not.
+  bool IsFunctionDecl = isa<FunctionDecl>(D);
+  if (S.LangOpts.MicrosoftMode &&
+      (!IsFunctionDecl || (PD && !PD->isFunctionDefinition()))) {

I'm trying to find a way to avoid passing the Declarator through to
here, but I assume you've looked and I can't find anything either...
All of the definition-related checks rely on Body which isn't set
until the body parsing is finished.

If it were a TagDecl we could say 'D->isBeingDefined()', but for
functions it looks like we haven't needed that.  Maybe it's worth
adding a IsDefinition or BeingDefined bit to FunctionDecl?  Would
anyone else find that useful or is it a bad idea?

+    S.Diag(Attr.getLoc(), diag::err_attribute_wrong_decl_type)
+      << Attr.getName() << ExpectedFunctionDefinition;
+    return;
+  } else if (!IsFunctionDecl) {
     S.Diag(Attr.getLoc(), diag::warn_attribute_wrong_decl_type)
       << Attr.getName() << ExpectedFunction;
     return;
@@ -4699,7 +4715,8 @@


On Fri, May 3, 2013 at 9:09 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
> MSVC handles the naked attribute differently than clang does.
> Specifically, in MSVC the __declspec(naked) must attach to a function
> *definition*, and failure to do so will result in an error.
>
> This patch brings clang's behavior more in line with MSVC's for
> __declspec(naked) in MS compatibility mode.  This does not modify the
> behavior of the codegen for naked functions (as is being discussed
> elsewhere).
>
> ~Aaron
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>