[patch] Fix linkage computation for derived types in inline functions

[Rafael Espíndola]

> 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".)

Actually, it looks like we should prefer internal to visibleNoLinkage.
Check test11 on the patch. This agrees with GCC, and seems reasonable.
Do you think it is wrong?

> Also, did you check that all of the bit-fields you increased still pack
> efficiently?

It was not. The new patch fixes that. I have only checked sizeof(Decl)
and sizeof(Type). On 32 bits they are 20 and 12. On 64 bits they are
32 and 24. These are the same values I get on trunk.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 12575 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130523/2b503ed8/attachment.obj>