[cfe-commits] [PR10113][patch] Don't consider template arguments when the visibility is already explicit

Rafael Ávila de Espíndola rafael.espindola at gmail.com
Sun Jan 1 17:53:00 PST 2012

> Anyway, I'm not actually convinced there's a bug here: unless I'm
> mistaken, there isn't any legal way to refer to a type with hidden
> visibility outside the shared library where it is defined.  Or am I
> missing something?

If the "struct zed" definition is on a header, it is should be possible
to include that header when building a library with -fvisibility=hidden
and use the same header in a program that uses that library.

> This falls out of my question as well -- why doesn't merge DTRT here?
> Put another way, once we encounter an explicit visibility specification
> for a declaration, why would we ever merge it away? (This is distinct
> from computing a visibility for a declaration from that of a set of N
> other declarations, some of which use an explicit visibility spec, some
> of which do not.) I feel like we should have better logic to make an
> explicit visibility spec trump all else while still merging linkage....
> The current logic for merging of explicitly specified visibility makes
> no sense to me.

I tested this and it works. It also found another bug in the way we
merge visibilities. An update patch is attached.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pr10113.patch
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120101/25b37501/attachment.ksh>

More information about the cfe-commits mailing list