[swift-dev] Inability to leverage privacy in the stdlib

[Erik Eckstein]

> On Oct 28, 2016, at 5:01 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Oct 28, 2016, at 17:00, Erik Eckstein <eeckstein at apple.com <mailto:eeckstein at apple.com>> wrote:
>> 
>>> 
>>> On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>> 
>>>> On Oct 23, 2016, at 16:13, Michael Gottesman <mgottesman at apple.com <mailto:mgottesman at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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.

Currently the rule is that a fragile function (= inlinable, AFAIK) cannot call a non-public non-fragile function. And with -sil-serialize-all all functions are set to fragile.
This is checked in the SILVerifier, which is of course not the right way to do the check (Slava told me he is going to make this a compiler warning instead, or something like this).

> 
>> 
>>> 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 at swift.org <mailto:swift-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161028/47a504ec/attachment.html>