On Apr 10, 2012, at 7:36 AM, Francois Pichet wrote: > On Mon, Apr 9, 2012 at 1:34 PM, John McCall <[email protected]> wrote: >> On Apr 8, 2012, at 2:29 AM, Francois Pichet wrote: >>> On Fri, Apr 6, 2012 at 11:04 PM, John McCall <[email protected]> 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? John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
