> On Oct 23, 2016, at 16:13, Michael Gottesman <mgottes...@apple.com> wrote:
>
>
>> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev
>> <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 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> 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
