On May 22, 2013, at 9:10 PM, Rafael Espíndola <[email protected]>
wrote:
> John noticed that the fix for pr15930 (r181981) didn't handle indirect
> uses of local types. For example, a pointer to local struct, or a
> function that returns it.
>
> One way to implement this would be to recursively look for local
> types. This would look a lot like the linkage computation itself for
> types.
>
> To avoid code duplication and utilize the existing linkage cache, this
> patch just makes the computation of "type with no linkage but
> externally visible because it is from an inline function" part of the
> linkage computation itself.
Hmm, there's a subtle change in assumptions here, because the
linkage enum is no longer a simple continuum.
Previously, merging two linkages just meant taking their minimum.
For example, consider the type T(*)(U):
- it has no linkage if either T or U has no linkage; or else
- it has internal linkage if either T or U has internal linkage; or else
- it has unique external linkage if either T or U has unique external
linkage; or else
- it has external linkage.
But if T has VisibleNoLinkage and U has NoLinkage, InternalLinkage,
or UniqueExternalLinkage, then T(*)(U) has NoLinkage.
(This is slightly artificial; IIRC, the notion of types having linkage is
not in the standard. But it's the right computation for rules that *are*
in the standard directly, like "template arguments can't involve a
declaration lacking external linkage".)
Also, did you check that all of the bit-fields you increased still pack
efficiently?
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
