On Tue, Apr 10, 2012 at 2:53 PM, John McCall <[email protected]> wrote: > 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? >
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). _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
