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