<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 23, 2016, at 16:13, Michael Gottesman <<a href="mailto:mgottesman@apple.com" class="">mgottesman@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class="">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.<br class=""><br class="">Can anyone recall why this is? How hard is it to fix?<br class=""></blockquote><br class="">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.</div></div></blockquote><br class=""></div><div class="">I don't have it all paged in, but there are three main pieces I remember:</div><div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">- 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.)</div><div class=""><br class=""></div><div class="">- 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.</div></div></div></blockquote><div><br class=""></div><div>This was the case (long time ago). But now the SIL linkage is not affected by -sil-serialize-all, just the llvm linkage.</div><div>But maybe you are referring to another issue.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> 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.</div><div class=""><br class=""></div><div class="">docs/AccessControlInStdlib.rst points to another, similar issue: <<a href="rdar://problem/17631278" class="">rdar://problem/17631278</a>> 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 <i class="">file</i> you declare something in should never be part of the library's ABI. (There are other answers that could work here, of course.)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>