[cfe-commits] r154248 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td include/clang/Sema/Sema.h lib/Sema/SemaAccess.cpp lib/Sema/SemaDeclCXX.cpp lib/Sema/SemaExprCXX.cpp lib/Sema/SemaInit.cpp test/CXX/class.access/class.protected/p1.c
Francois Pichet
pichet2000 at gmail.com
Tue Apr 17 05:38:14 PDT 2012
On Tue, Apr 10, 2012 at 2:53 PM, John McCall <rjmccall at apple.com> wrote:
> On Apr 10, 2012, at 7:36 AM, Francois Pichet wrote:
>> On Mon, Apr 9, 2012 at 1:34 PM, John McCall <rjmccall at apple.com> wrote:
>>> On Apr 8, 2012, at 2:29 AM, Francois Pichet wrote:
>>>> On Fri, Apr 6, 2012 at 11:04 PM, John McCall <rjmccall at apple.com> wrote:
>>>>> Author: rjmccall
>>>>> Date: Fri Apr 6 22:04:20 2012
>>>>> New Revision: 154248
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=154248&view=rev
>>>>> Log:
>>>>> Fix several problems with protected access control:
>>>>> - The [class.protected] restriction is non-trivial for any instance
>>>>> member, even if the access lacks an object (for example, if it's
>>>>> a pointer-to-member constant). In this case, it is equivalent to
>>>>> requiring the naming class to equal the context class.
>>>>> - The [class.protected] restriction applies to accesses to constructors
>>>>> and destructors. A protected constructor or destructor can only be
>>>>> used to create or destroy a base subobject, as a direct result.
>>>>> - Several places were dropping or misapplying object information.
>>>>>
>>>>> The standard could really be much clearer about what the object type is
>>>>> supposed to be in some of these accesses. Usually it's easy enough to
>>>>> find a reasonable answer, but still, the standard makes a very confident
>>>>> statement about accesses to instance members only being possible in
>>>>> either pointer-to-member literals or member access expressions, which
>>>>> just completely ignores concepts like constructor and destructor
>>>>> calls, using declarations, unevaluated field references, etc.
>>>>>
>>>>
>>>> Hi John,
>>>> I am not asking you to make the modification but do you have any
>>>> suggestion about how to handle case like that in MicrosoftMode?
>>>>
>>>> class A {
>>>> protected:
>>>> void f();
>>>> };
>>>>
>>>> class B : public A{
>>>> public:
>>>> void test();
>>>> };
>>>>
>>>> void B::test() {
>>>> &A::f;
>>>> }
>>>
>>>
>>> It should be trivial to disable the additional restrictions in MicrosoftMode.
>>> Does MSVC implement the protected member access restriction at all,
>>> or does it just miss it in the case of pointer-to-members?
>>>
>>> Try this:
>>>
>>> void B::test() {
>>> A *a = 0;
>>> a->f();
>>> }
>>
>> MSVC will give an error for this case.
>> So MSVC just seem to miss the pointer-to-members case and this cause a
>> regression with MFC code.
>
> Okay. Then I think the right thing to do is to just add something like
> if (S.getLangOpts().MicrosoftMode) return AR_accessible;
> with the appropriate comment somewhere around SemaAccess.cpp:782.
> Would you mind fleshing out a patch and testcases for that?
>
r154924,
BTW my example was wrong. MSVC will correctly reject that. MSVC will
only allow the protected access to a PTM if it is from a static
function. (see my test case example).
More information about the cfe-commits
mailing list