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

[Aaron Ballman]

After a chat with rnk on IRC, here is another attempt at the patch.
This does not move the work over to the FunctionDecl; I think its
expense exceeds its worth since it bumps the number of bits in the bit
field over a power of 2 boundary for this one use case.  However, this
patch does ensure that __attribute__ is still allowed on a declaration
in ms-compat mode and updates the test case appropriately.

~Aaron

On Sat, May 4, 2013 at 11:02 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
> On Fri, May 3, 2013 at 6:43 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>> On Fri, May 3, 2013 at 10:02 AM, Reid Kleckner <rnk at google.com> wrote:
>>>
>>> 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?
>>
>>
>> This seems reasonable to me, although I'm not sure how generally useful it
>> would be.
>
> Do you think it would be a better approach than the current one given
> the lack of general usefulness?
>
> ~Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: naked.patch
Type: application/octet-stream
Size: 8098 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130509/0555381f/attachment.obj>