> On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev <swift-dev@swift.org> > wrote: > > >> On Oct 23, 2016, at 16:13, Michael Gottesman <mgottes...@apple.com >> <mailto:mgottes...@apple.com>> wrote: >> >> >>> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev >>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>> >>> Dave pointed out to me this week that the build crashes if the stdlib tries >>> to use private/fileprivate. I tried it myself and lo and behold the linker >>> can't find the private symbols. He couldn't recall what about the build >>> caused that, though. >>> >>> Can anyone recall why this is? How hard is it to fix? >> >> I am not 100% sure, but if it happens only with the stdlib and has to do >> with access control, I wouldn't be surprised if it has to do with >> -sil-serialize-all and friends. But I may be correct. I think Jordan is the >> right person to answer this question. > > I don't have it all paged in, but there are three main pieces I remember: > > - Private and fileprivate decls can of course conflict across file > boundaries, which means it's possible we wouldn't be able to rebuild the > standard library from textual SIL. I think this is just a hypothetical > concern, since we don't actually have a reason to reuse names. > > - Textual SIL again: the mangling for a private decl depends on its file. We > could fix this with an attribute that hardcodes manglings, or hardcodes a > private discriminator, or something. (We also have a bug today where multiple > 'private' decls in the same file will conflict in their mangling.) > > - The standard library currently builds with -sil-serialize-all ("magic > performance mode") to make everything inlinable. This option currently mucks > with linkages at the SIL level in a fairly unprincipled way.
This was the case (long time ago). But now the SIL linkage is not affected by -sil-serialize-all, just the llvm linkage. But maybe you are referring to another issue. > This is probably the underlying cause of whatever linking issues you're > seeing, but even if it's not it would probably get in the way of trying to > fix things. > > docs/AccessControlInStdlib.rst points to another, similar issue: > <rdar://problem/17631278 <rdar://problem/17631278>> Figure out how inlined > XREFs to private entities work. Our planned answer for this is that inlinable > things can't reference private entities, only internal ones (and even then > only those marked as "versioned"). That's a bit annoying, but does correspond > with the notion that a versioned entity is an ABI promise, and the file you > declare something in should never be part of the library's ABI. (There are > other answers that could work here, of course.) > > Fortunately those last issues are something we need to fix anyway as part of > deciding which parts of the standard library should be resilient and which > parts are fragile, so maybe we'll be in a good enough place to start allowing > private decls again later this release. > > Jordan > > > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
