[cfe-commits] r154924 - in /cfe/trunk: lib/Sema/SemaAccess.cpp test/Parser/MicrosoftExtensions.cpp

[Francois Pichet]

On Tue, Apr 17, 2012 at 2:04 PM, John McCall <rjmccall at apple.com> wrote:
> On Apr 17, 2012, at 5:35 AM, Francois Pichet wrote:
>> Author: fpichet
>> Date: Tue Apr 17 07:35:05 2012
>> New Revision: 154924
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=154924&view=rev
>> Log:
>> Emulate a MSVC bug where the creation of pointer-to-member to protected member of base class is allowed but only from a static function.
>>
>> This fixes a regression when parsing MFC code with clang.
>>
>> Modified:
>>    cfe/trunk/lib/Sema/SemaAccess.cpp
>>    cfe/trunk/test/Parser/MicrosoftExtensions.cpp
>>
>> Modified: cfe/trunk/lib/Sema/SemaAccess.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaAccess.cpp?rev=154924&r1=154923&r2=154924&view=diff
>> ==============================================================================
>> --- cfe/trunk/lib/Sema/SemaAccess.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaAccess.cpp Tue Apr 17 07:35:05 2012
>> @@ -779,6 +779,13 @@
>>         // that the naming class has to be derived from the effective
>>         // context.
>>
>> +        // Emulate a MSVC bug where the creation of pointer-to-member
>> +        // to protected member of base class is allowed but only from
>> +        // a static function.
>> +        if (S.getLangOpts().MicrosoftMode && !EC.Functions.empty() &&
>> +            EC.Functions.front()->getStorageClass() == SC_Static)
>> +           return AR_accessible;
>> +
>
> You should really be testing whether this is a non-instance
> CXXMethodDecl;  right now this will trigger on namespace-level
> static functions.  I guess you should try different combinations in MSVC
> and see what makes it trigger.

Good point, see r154982.

> Also, when I suggested this, I was assuming this could reasonably be
> discussed as a dialect difference.  This just sounds like a bug.  Did we
> definitely decide to emulate MSVC bug-for-bug?  If this is blocking some
> system header, we might want to target the fix more narrowly at that
> specific code — we actually have some similar workarounds for
> emulating GCC bugs in specific system headers.

The difference between dialect difference and a bug is not clear to me
in this case. Clearly we don't want to emulate MSVC bug-for-bug in all
cases. In this case, this is blocking the parsing of the default
wizard generated MFC project and the fix is fairly minor (3 lines of
code) so I think we are fine.