> On Oct 28, 2016, at 17:00, Erik Eckstein <eeckst...@apple.com> wrote: > >> >> On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev <swift-dev@swift.org >> <mailto: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.
Then I guess it’s the same issue the other way around: we don’t muck with the real linkage enough to make the symbols actually public. Again, being principled about what an inlinable function can and can’t refer to would help here. > >> 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 <mailto: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
