[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...
More information about the cfe-commits