On Thu, May 23, 2013 at 12:23 AM, John McCall <[email protected]> wrote:
> On May 22, 2013, at 11:48 PM, Richard Smith <[email protected]> wrote: > > On Wed, May 22, 2013 at 9:34 PM, John McCall <[email protected]> wrote: > >> 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 return 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 seems to be a step towards what I think is the right end result. We > have two separate notions: the formal language linkage, and whether an > entity is externally visible. To that end: > > (external, visible) -> ExternalLinkage > (external, not visible) -> UniqueExternalLinkage [*] > (internal, visible) -> not possible > (internal, not visible) -> InternalLinkage > (no linkage, visible) -> VisibleNoLinkage > (no linkage, not visible) -> NoLinkage > > ... and the combining step takes the minimum on each axis. > > If we're going to three bits anyway, it would make more sense to me to > separate out the two notions. > > > That makes sense to me. > > [*] Templates instantiated with non-visible arguments are also technically > in this bucket, and we give them InternalLinkage or NoLinkage, but there's > a DR pending which might change the linkage of those specializations to > match our behavior. > > > Okay. > > (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".) >> > > Per the standard, (some) types do have linkage... > > > I thought that was just the declared types. > Assuming I'm not misunderstanding what you're looking for here, this is handled by N3690 [basic.link]p8: "A type is said to have linkage if and only if ...", which covers all (canonical) types.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
