r175326 - Rework the visibility computation algorithm in preparation

John McCall rjmccall at apple.com
Tue Feb 19 17:57:09 PST 2013


On Feb 19, 2013, at 1:07 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:
>> Rework the visibility computation algorithm in preparation
>> for distinguishing type vs. value visibility.
>> 
>> The changes to the visibility of explicit specializations
>> are intentional.
> 
> Thanks. It is indeed much cleaner to ignore other sources when a
> specialization explicitly says what visibility should be used. A
> change that looks unintended is that in
> 
>  struct HIDDEN foo {
>  };
>  template <class P>
>  struct bar {
>    static DEFAULT void zed();
>  };
>  template <class P>
>  void bar<P>::zed() {
>  }
> 
>  //template class bar<foo>;
> 
>  void test() {
>    bar<foo>::zed();
>  }
> 
> We produce a hidden symbol for zed, but uncommenting the explicit
> template instantiation causes us to produce a default symbol. The idea
> was for explicit template instantiations to make a difference only if
> they have an attribute, no?

Yeah, we should not have been ignoring template argument visibility
in explicit instantiations just because there was a (pattern) member
with explicit visibility.  This is fixed in r175587.

John.





More information about the cfe-commits mailing list