> On Oct 28, 2016, at 5:01 PM, Jordan Rose <jordan_r...@apple.com> wrote: > > >> On Oct 28, 2016, at 17:00, Erik Eckstein <eeckst...@apple.com >> <mailto: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.
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@swift.org <mailto:swift-dev@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-dev >>> <https://lists.swift.org/mailman/listinfo/swift-dev>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
