<div class="gmail_quote">On Tue, Jun 29, 2010 at 8:13 AM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Jun 28, 2010, at 1:39 AM, Chandler Carruth wrote:<br>
<br>
> Author: chandlerc<br>
> Date: Mon Jun 28 03:39:25 2010<br>
> New Revision: 106993<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=106993&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=106993&view=rev</a><br>
> Log:<br>
> Partial fix for PR7267 based on comments by John McCall on an earlier patch.<br>
> This is more targeted, as it simply provides toggle actions for the parser to<br>
> turn access checking on and off. We then use these to suppress access checking<br>
> only while we parse the template-id (included scope specifier) of an explicit<br>
> instantiation and explicit specialization of a class template. The<br>
> specialization behavior is an extension, as it seems likely a defect that the<br>
> standard did not exempt them as it does explicit instantiations.<br>
<br>
</div>Both EDG and g++ seem to allow this "extension", too.<br>
<div><div></div><div class="h5"><br>
> Modified: cfe/trunk/lib/Parse/ParseDeclCXX.cpp<br>
> URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDeclCXX.cpp?rev=106993&r1=106992&r2=106993&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDeclCXX.cpp?rev=106993&r1=106992&r2=106993&view=diff</a><br>

> ==============================================================================<br>
> --- cfe/trunk/lib/Parse/ParseDeclCXX.cpp (original)<br>
> +++ cfe/trunk/lib/Parse/ParseDeclCXX.cpp Mon Jun 28 03:39:25 2010<br>
> @@ -613,6 +613,20 @@<br>
>     ConsumeCodeCompletionToken();<br>
>   }<br>
><br>
> +  // C++03 [temp.explicit] 14.7.2/8:<br>
> +  //   The usual access checking rules do not apply to names used to specify<br>
> +  //   explicit instantiations.<br>
> +  //<br>
> +  // As an extension we do not perform access checking on the names used to<br>
> +  // specify explicit specializations either. This is important to allow<br>
> +  // specializing traits classes for private types.<br>
> +  bool SuppressingAccessChecks = false;<br>
> +  if (TemplateInfo.Kind == ParsedTemplateInfo::ExplicitInstantiation ||<br>
> +      TemplateInfo.Kind == ParsedTemplateInfo::ExplicitSpecialization) {<br>
> +    Actions.ActOnStartSuppressingAccessChecks();<br>
> +    SuppressingAccessChecks = true;<br>
> +  }<br>
> +<br>
>   AttributeList *AttrList = 0;<br>
>   // If attributes exist after tag, parse them.<br>
>   if (Tok.is(tok::kw___attribute))<br>
> @@ -732,10 +746,18 @@<br>
>       DS.SetTypeSpecError();<br>
>       SkipUntil(tok::semi, false, true);<br>
>       TemplateId->Destroy();<br>
> +      if (SuppressingAccessChecks)<br>
> +        Actions.ActOnStopSuppressingAccessChecks();<br>
> +<br>
>       return;<br>
>     }<br>
>   }<br>
><br>
> +  // As soon as we're finished parsing the class's template-id, turn access<br>
> +  // checking back on.<br>
> +  if (SuppressingAccessChecks)<br>
> +    Actions.ActOnStopSuppressingAccessChecks();<br>
> +<br>
>   // There are four options here.  If we have 'struct foo;', then this<br>
>   // is either a forward declaration or a friend declaration, which<br>
>   // have to be treated differently.  If we have 'struct foo {...' or<br>
<br>
</div></div>I'd feel a bit more comfortable if this were an RAII object.<br></blockquote><div><br></div><div>As would I, but John seemed to think that was overkill in his email about the original patch... maybe I was mis-interpreting him though? I'm happy to switch if you like.</div>
</div>