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?
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.
What do you think Jordan?
Michael
On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev <swift-dev@swift.org> wrote:
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
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
On Oct 23, 2016, at 16:13, Michael Gottesman <mgottesman@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.
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.
What do you think Jordan?
Michael
Hi Alexis,
You can build the stdlib without sil-serialize-all now by passing a flag to build-script:
./utils/build-script — --swift-stdlib-enable-resilience
Give that a shot and see if it fixes the issues you’re having with ‘private’.
On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev <swift-dev@swift.org> wrote:
On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev <swift-dev@swift.org> wrote:
_______________________________________________
swift-dev mailing list
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
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.
On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:
On Oct 23, 2016, at 16:13, Michael Gottesman <mgottesman@apple.com <mailto:mgottesman@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:
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
https://lists.swift.org/mailman/listinfo/swift-dev
Won't merging anything relying on this flag break the build? Is this going to become the "new" default soon?
On Oct 28, 2016, at 6:43 PM, Slava Pestov <spestov@apple.com> wrote:
On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev <swift-dev@swift.org> 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.
What do you think Jordan?
MichaelHi Alexis,
You can build the stdlib without sil-serialize-all now by passing a flag to build-script:
./utils/build-script — --swift-stdlib-enable-resilience
Give that a shot and see if it fixes the issues you’re having with ‘private’.
_______________________________________________
swift-dev mailing list
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
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.
On Oct 28, 2016, at 17:00, Erik Eckstein <eeckstein@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 <mgottesman@apple.com <mailto:mgottesman@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:
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
It will become the default, but not yet, so yeah, you shouldn’t merge anything that only builds with this flag set.
Can you share the patch that adds private modifiers along with the linker errors you are seeing? Now would be a good time to sort out these issues.
On Oct 28, 2016, at 4:16 PM, Alexis Beingessner <abeingessner@apple.com> wrote:
Won't merging anything relying on this flag break the build? Is this going to become the "new" default soon?
On Oct 28, 2016, at 6:43 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> 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.
What do you think Jordan?
MichaelHi Alexis,
You can build the stdlib without sil-serialize-all now by passing a flag to build-script:
./utils/build-script — --swift-stdlib-enable-resilience
Give that a shot and see if it fixes the issues you’re having with ‘private’.
_______________________________________________
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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev
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).
On Oct 28, 2016, at 5:01 PM, Jordan Rose <jordan_rose@apple.com> wrote:
On Oct 28, 2016, at 17:00, Erik Eckstein <eeckstein@apple.com <mailto:eeckstein@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 <mgottesman@apple.com <mailto:mgottesman@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:
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
It will become the default, but not yet, so yeah, you shouldn’t merge anything that only builds with this flag set.
Can you share the patch that adds private modifiers along with the linker errors you are seeing? Now would be a good time to sort out these issues.
I’m actually having trouble reproducing this now? I just rebased my branches onto master and using private/fileprivate on types, aliases, and functions seems to work perfectly fine (I tried a few things in Array and Dictionary). Did something interesting just get merged?
On Oct 29, 2016, at 12:13 AM, Slava Pestov <spestov@apple.com> wrote:
On Oct 28, 2016, at 4:16 PM, Alexis Beingessner <abeingessner@apple.com <mailto:abeingessner@apple.com>> wrote:
Won't merging anything relying on this flag break the build? Is this going to become the "new" default soon?
On Oct 28, 2016, at 6:43 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> 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.
What do you think Jordan?
MichaelHi Alexis,
You can build the stdlib without sil-serialize-all now by passing a flag to build-script:
./utils/build-script — --swift-stdlib-enable-resilience
Give that a shot and see if it fixes the issues you’re having with ‘private’.
_______________________________________________
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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev
It will become the default, but not yet, so yeah, you shouldn’t merge anything that only builds
with this flag set.
Can you share the patch that adds private modifiers along with the
linker errors you are seeing? Now would be a good time to sort out
these issues.I’m actually having trouble reproducing this now? I just rebased my
branches onto master and using private/fileprivate on types, aliases,
and functions seems to work perfectly fine (I tried a few things in
Array and Dictionary). Did something interesting just get merged?
I suggest you try making and testing a pull request. Often things seem
to work because of the way we build and test locally, but fail in the
full CI environment.
on Sat Oct 29 2016, Alexis <swift-dev-AT-swift.org> wrote:
On Oct 29, 2016, at 12:13 AM, Slava Pestov <spestov@apple.com> wrote:
On Oct 28, 2016, at 4:16 PM, Alexis Beingessner <abeingessner@apple.com > <mailto:abeingessner@apple.com>> wrote:
Won't merging anything relying on this flag break the build? Is this going to become the "new"
default soon?
On Oct 28, 2016, at 6:43 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev >>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> 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.What do you think Jordan?
MichaelHi Alexis,
You can build the stdlib without sil-serialize-all now by passing a flag to build-script:
./utils/build-script — --swift-stdlib-enable-resilience
Give that a shot and see if it fixes the issues you’re having with ‘private’.
_______________________________________________
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 <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
--
-Dave
I made a PR with some basic privacy usage for Array, and everything seems to be working on OSX, but not Linux.
Exit Code: 1
Command Output (stderr):
--
/usr/bin/ld.gold: error: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o): multiple definition of '_TTSfq4n_d___TTSgq5Si___TZFVs15ContiguousArrayP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o): previous definition here
/usr/bin/ld.gold: error: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o): multiple definition of '_TTSfq4n_d___TTSgq5Vs4Int8___TZFSaP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o): previous definition here
/usr/bin/ld.gold: error: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o): multiple definition of '_TTSfq4n_d___TTSgq5Vs5UInt8___TZFSaP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o): previous definition here
clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)
--
Close... (made copyBuffer private)
On Oct 29, 2016, at 6:04 PM, Dave Abrahams via swift-dev <swift-dev@swift.org> wrote:
on Sat Oct 29 2016, Alexis <swift-dev-AT-swift.org <http://swift-dev-at-swift.org/>> wrote:
On Oct 29, 2016, at 12:13 AM, Slava Pestov <spestov@apple.com> wrote:
It will become the default, but not yet, so yeah, you shouldn’t merge anything that only builds
with this flag set.
Can you share the patch that adds private modifiers along with the
linker errors you are seeing? Now would be a good time to sort out
these issues.I’m actually having trouble reproducing this now? I just rebased my
branches onto master and using private/fileprivate on types, aliases,
and functions seems to work perfectly fine (I tried a few things in
Array and Dictionary). Did something interesting just get merged?I suggest you try making and testing a pull request. Often things seem
to work because of the way we build and test locally, but fail in the
full CI environment.On Oct 28, 2016, at 4:16 PM, Alexis Beingessner <abeingessner@apple.com <mailto:abeingessner@apple.com> >> <mailto:abeingessner@apple.com <mailto:abeingessner@apple.com>>> wrote:
Won't merging anything relying on this flag break the build? Is this going to become the "new"
default soon?
On Oct 28, 2016, at 6:43 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com> <mailto:spestov@apple.com <mailto:spestov@apple.com>>> wrote:
On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev >>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>>> wrote:
On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev >>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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.What do you think Jordan?
MichaelHi Alexis,
You can build the stdlib without sil-serialize-all now by passing a flag to build-script:
./utils/build-script — --swift-stdlib-enable-resilience
Give that a shot and see if it fixes the issues you’re having with ‘private’.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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 <mailto:swift-dev@swift.org> <mailto: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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev--
-Dave_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev
Hmm, I excitedly prototyped out refactoring HashedCollections to properly use privacy and decent naming since I’m clobbering the whole file with the new indexing stuff anyway. Unfortunately I hit a linker error. I can’t seem to produce a reduced test case. Making similar but smaller changes to other files seems to always work.
The commit of interest is this:
But it requires all the native indexing stuff I’ve done:
https://github.com/apple/swift/compare/master...Gankro:dsindex2?expand=1 <https://github.com/apple/swift/compare/master...Gankro:dsindex2?expand=1>
The error I get:
FAILED: : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -fno-stack-protector -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -Wdocumentation -Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -O2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -dynamiclib -Wl,-headerpad_max_install_names -stdlib=libc++ -target x86_64-apple-macosx10.9 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -arch x86_64 -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/../../../Developer/Library/Frameworks -mmacosx-version-min=10.9 -lobjc -Wl,-sectcreate,__TEXT,__info_plist,/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/internal/SwiftExperimental/Info.plist -Wl,-application_extension -L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/./lib/swift/macosx/x86_64 -L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/./bin/../lib/swift/macosx/x86_64 -L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/./bin/../lib/swift/macosx -o lib/swift/macosx/x86_64/libswiftSwiftExperimental.dylib -install_name @rpath/libswiftSwiftExperimental.dylib stdlib/internal/SwiftExperimental/macosx/x86_64/SwiftExperimental.o -L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./lib lib/swift/macosx/x86_64/libswiftCore.dylib -framework Foundation -framework CoreFoundation && :
Undefined symbols for architecture x86_64:
"type metadata accessor for Swift.(VariantSetStorage in _69BD46AE5A11D8B70E9CADC1ECE9CF76)", referenced from:
Swift.Set.formUnion <A where A1: Swift.Sequence, A == A1.Iterator.Element> (A1) -> () in SwiftExperimental.o
Swift.Set.init <A where A1: Swift.Sequence, A == A1.Iterator.Element> (A1) -> Swift.Set<A> in SwiftExperimental.o
Swift.Set.intersection (Swift.Set<A>) -> Swift.Set<A> in SwiftExperimental.o
Swift.Set.formSymmetricDifference (Swift.Set<A>) -> () in SwiftExperimental.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[648/1027] Compiling /Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/public/SwiftOnoneSupport/macosx/x86_64/SwiftOnoneSupport.o
ninja: build stopped: subcommand failed.
utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
On Nov 1, 2016, at 12:10 PM, Alexis via swift-dev <swift-dev@swift.org> wrote:
I made a PR with some basic privacy usage for Array, and everything seems to be working on OSX, but not Linux.
[test] check that privacy works by Gankra · Pull Request #5573 · apple/swift · GitHub
Exit Code: 1
Command Output (stderr):
--
/usr/bin/ld.gold: error: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o): multiple definition of '_TTSfq4n_d___TTSgq5Si___TZFVs15ContiguousArrayP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o): previous definition here
/usr/bin/ld.gold: error: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o): multiple definition of '_TTSfq4n_d___TTSgq5Vs4Int8___TZFSaP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o): previous definition here
/usr/bin/ld.gold: error: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o): multiple definition of '_TTSfq4n_d___TTSgq5Vs5UInt8___TZFSaP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold: /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o): previous definition here
clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)--
Close... (made copyBuffer private)
On Oct 29, 2016, at 6:04 PM, Dave Abrahams via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
on Sat Oct 29 2016, Alexis <swift-dev-AT-swift.org <http://swift-dev-at-swift.org/>> wrote:
On Oct 29, 2016, at 12:13 AM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
It will become the default, but not yet, so yeah, you shouldn’t merge anything that only builds
with this flag set.
Can you share the patch that adds private modifiers along with the
linker errors you are seeing? Now would be a good time to sort out
these issues.I’m actually having trouble reproducing this now? I just rebased my
branches onto master and using private/fileprivate on types, aliases,
and functions seems to work perfectly fine (I tried a few things in
Array and Dictionary). Did something interesting just get merged?I suggest you try making and testing a pull request. Often things seem
to work because of the way we build and test locally, but fail in the
full CI environment.On Oct 28, 2016, at 4:16 PM, Alexis Beingessner <abeingessner@apple.com <mailto:abeingessner@apple.com> >>> <mailto:abeingessner@apple.com <mailto:abeingessner@apple.com>>> wrote:
Won't merging anything relying on this flag break the build? Is this going to become the "new"
default soon?
On Oct 28, 2016, at 6:43 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com> <mailto:spestov@apple.com <mailto:spestov@apple.com>>> wrote:
On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev >>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>>> wrote:
On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev >>>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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.What do you think Jordan?
MichaelHi Alexis,
You can build the stdlib without sil-serialize-all now by passing a flag to build-script:
./utils/build-script — --swift-stdlib-enable-resilience
Give that a shot and see if it fixes the issues you’re having with ‘private’.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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 <mailto:swift-dev@swift.org> <mailto: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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev--
-Dave_______________________________________________
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
Hmm, I excitedly prototyped out refactoring HashedCollections to
properly use privacy and decent naming since I’m clobbering the whole
file with the new indexing stuff anyway. Unfortunately I hit a linker
error. I can’t seem to produce a reduced test case.
If you are doing privacy inside the stdlib, then this is similar to the
experience I recall having the last time I tried to do it. I'm pretty
sure that's what the frontend team means when they say that it's
unsupported.
on Tue Nov 01 2016, Alexis <swift-dev-AT-swift.org> wrote:
Making similar but smaller changes to other files seems to always
work.The commit of interest is this:
temp · apple/swift@851228a · GitHub
<https://github.com/apple/swift/commit/851228a1d59e292b020c16a0fba4561a76f8fec5>But it requires all the native indexing stuff I’ve done:
https://github.com/apple/swift/compare/master...Gankro:dsindex2?expand=1
<https://github.com/apple/swift/compare/master...Gankro:dsindex2?expand=1>The error I get:
FAILED: : &&
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-fno-stack-protector -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -Wdocumentation
-Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -O2 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-dynamiclib -Wl,-headerpad_max_install_names -stdlib=libc++ -target x86_64-apple-macosx10.9
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-arch x86_64 -F
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/../../../Developer/Library/Frameworks
-mmacosx-version-min=10.9 -lobjc
-Wl,-sectcreate,__TEXT,__info_plist,/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/internal/SwiftExperimental/Info.plist
-Wl,-application_extension
-L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/./lib/swift/macosx/x86_64
-L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/./bin/../lib/swift/macosx/x86_64
-L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/./bin/../lib/swift/macosx
-o lib/swift/macosx/x86_64/libswiftSwiftExperimental.dylib -install_name
@rpath/libswiftSwiftExperimental.dylib
stdlib/internal/SwiftExperimental/macosx/x86_64/SwiftExperimental.o
-L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./lib
lib/swift/macosx/x86_64/libswiftCore.dylib -framework Foundation -framework CoreFoundation && :
Undefined symbols for architecture x86_64:
"type metadata accessor for Swift.(VariantSetStorage in _69BD46AE5A11D8B70E9CADC1ECE9CF76)",
referenced from:
Swift.Set.formUnion <A where A1: Swift.Sequence, A == A1.Iterator.Element> (A1) -> () in
SwiftExperimental.o
Swift.Set.init <A where A1: Swift.Sequence, A == A1.Iterator.Element> (A1) -> Swift.Set<A> in
SwiftExperimental.o
Swift.Set.intersection (Swift.Set<A>) -> Swift.Set<A> in SwiftExperimental.o
Swift.Set.formSymmetricDifference (Swift.Set<A>) -> () in SwiftExperimental.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[648/1027] Compiling
/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/public/SwiftOnoneSupport/macosx/x86_64/SwiftOnoneSupport.o
ninja: build stopped: subcommand failed.
utils/build-script: fatal error: command terminated with a non-zero exit status 1, abortingOn Nov 1, 2016, at 12:10 PM, Alexis via swift-dev <swift-dev@swift.org> wrote:
I made a PR with some basic privacy usage for Array, and everything seems to be working on OSX,
but not Linux.
[test] check that privacy works by Gankra · Pull Request #5573 · apple/swift · GitHub
Exit Code: 1
Command Output (stderr):
--
/usr/bin/ld.gold: error:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o):
multiple definition of
'_TTSfq4n_d___TTSgq5Si___TZFVs15ContiguousArrayP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o):
previous definition here
/usr/bin/ld.gold: error:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o):
multiple definition of
'_TTSfq4n_d___TTSgq5Vs4Int8___TZFSaP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o):
previous definition here
/usr/bin/ld.gold: error:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o):
multiple definition of
'_TTSfq4n_d___TTSgq5Vs5UInt8___TZFSaP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o):
previous definition here
clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)--
Close... (made copyBuffer private)
On Oct 29, 2016, at 6:04 PM, Dave Abrahams via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
on Sat Oct 29 2016, Alexis <swift-dev-AT-swift.org <http://swift-dev-at-swift.org/>> wrote:
On Oct 29, 2016, at 12:13 AM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com>> wrote:
It will become the default, but not yet, so yeah, you shouldn’t merge anything that only builds
with this flag set.
Can you share the patch that adds private modifiers along with the
linker errors you are seeing? Now would be a good time to sort out
these issues.I’m actually having trouble reproducing this now? I just rebased my
branches onto master and using private/fileprivate on types, aliases,
and functions seems to work perfectly fine (I tried a few things in
Array and Dictionary). Did something interesting just get merged?I suggest you try making and testing a pull request. Often things seem
to work because of the way we build and test locally, but fail in the
full CI environment.On Oct 28, 2016, at 4:16 PM, Alexis Beingessner <abeingessner@apple.com <mailto:abeingessner@apple.com> >>>> <mailto:abeingessner@apple.com <mailto:abeingessner@apple.com>>> wrote:
Won't merging anything relying on this flag break the build? Is this going to become the "new"
default soon?
On Oct 28, 2016, at 6:43 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com> <mailto:spestov@apple.com <mailto:spestov@apple.com>>> wrote:
On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev >>>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>>> wrote:
On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev >>>>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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.What do you think Jordan?
MichaelHi Alexis,
You can build the stdlib without sil-serialize-all now by passing a flag to build-script:
./utils/build-script — --swift-stdlib-enable-resilience
Give that a shot and see if it fixes the issues you’re having with ‘private’.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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 <mailto:swift-dev@swift.org> <mailto: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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev--
-Dave_______________________________________________
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_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
--
-Dave
The problem is if a private type or function X is referenced from a function Y with a serialized body, then if Y is inlined inside of another module, it cannot see the symbol for X. The solution is to disable -sil-seiralize-all and replace it with an explicit ‘fragile’ attribute that is put on certain functions only. I’m still working on this but it is almost ready to land.
Slava
On Nov 1, 2016, at 11:19 AM, Dave Abrahams via swift-dev <swift-dev@swift.org> wrote:
on Tue Nov 01 2016, Alexis <swift-dev-AT-swift.org <http://swift-dev-at-swift.org/>> wrote:
Hmm, I excitedly prototyped out refactoring HashedCollections to
properly use privacy and decent naming since I’m clobbering the whole
file with the new indexing stuff anyway. Unfortunately I hit a linker
error. I can’t seem to produce a reduced test case.If you are doing privacy inside the stdlib, then this is similar to the
experience I recall having the last time I tried to do it. I'm pretty
sure that's what the frontend team means when they say that it's
unsupported.Making similar but smaller changes to other files seems to always
work.The commit of interest is this:
temp · apple/swift@851228a · GitHub
<https://github.com/apple/swift/commit/851228a1d59e292b020c16a0fba4561a76f8fec5>But it requires all the native indexing stuff I’ve done:
https://github.com/apple/swift/compare/master...Gankro:dsindex2?expand=1 <https://github.com/apple/swift/compare/master...Gankro:dsindex2?expand=1>
<https://github.com/apple/swift/compare/master...Gankro:dsindex2?expand=1 <https://github.com/apple/swift/compare/master...Gankro:dsindex2?expand=1>>The error I get:
FAILED: : &&
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-fno-stack-protector -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wcovered-switch-default -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -Wdocumentation
-Wimplicit-fallthrough -Wunreachable-code -Woverloaded-virtual -O2 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-dynamiclib -Wl,-headerpad_max_install_names -stdlib=libc++ -target x86_64-apple-macosx10.9
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-arch x86_64 -F
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/../../../Developer/Library/Frameworks
-mmacosx-version-min=10.9 -lobjc
-Wl,-sectcreate,__TEXT,__info_plist,/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/internal/SwiftExperimental/Info.plist
-Wl,-application_extension
-L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/./lib/swift/macosx/x86_64
-L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/./bin/../lib/swift/macosx/x86_64
-L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/./bin/../lib/swift/macosx
-o lib/swift/macosx/x86_64/libswiftSwiftExperimental.dylib -install_name
@rpath/libswiftSwiftExperimental.dylib
stdlib/internal/SwiftExperimental/macosx/x86_64/SwiftExperimental.o
-L/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/llvm-macosx-x86_64/./lib
lib/swift/macosx/x86_64/libswiftCore.dylib -framework Foundation -framework CoreFoundation && :
Undefined symbols for architecture x86_64:
"type metadata accessor for Swift.(VariantSetStorage in _69BD46AE5A11D8B70E9CADC1ECE9CF76)",
referenced from:
Swift.Set.formUnion <A where A1: Swift.Sequence, A == A1.Iterator.Element> (A1) -> () in
SwiftExperimental.o
Swift.Set.init <A where A1: Swift.Sequence, A == A1.Iterator.Element> (A1) -> Swift.Set<A> in
SwiftExperimental.o
Swift.Set.intersection (Swift.Set<A>) -> Swift.Set<A> in SwiftExperimental.o
Swift.Set.formSymmetricDifference (Swift.Set<A>) -> () in SwiftExperimental.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[648/1027] Compiling
/Users/Beingessner/dev/swift/build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/stdlib/public/SwiftOnoneSupport/macosx/x86_64/SwiftOnoneSupport.o
ninja: build stopped: subcommand failed.
utils/build-script: fatal error: command terminated with a non-zero exit status 1, abortingOn Nov 1, 2016, at 12:10 PM, Alexis via swift-dev <swift-dev@swift.org> wrote:
I made a PR with some basic privacy usage for Array, and everything seems to be working on OSX,
but not Linux.
[test] check that privacy works by Gankra · Pull Request #5573 · apple/swift · GitHub <https://github.com/apple/swift/pull/5573>
Exit Code: 1
Command Output (stderr):
--
/usr/bin/ld.gold: error:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o):
multiple definition of
'_TTSfq4n_d___TTSgq5Si___TZFVs15ContiguousArrayP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o):
previous definition here
/usr/bin/ld.gold: error:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o):
multiple definition of
'_TTSfq4n_d___TTSgq5Vs4Int8___TZFSaP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o):
previous definition here
/usr/bin/ld.gold: error:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftSwiftOnoneSupport.a(SwiftOnoneSupport.o):
multiple definition of
'_TTSfq4n_d___TTSgq5Vs5UInt8___TZFSaP33_4E8E8F8E53AAC7AA89B428DCA7DB222B11_copyBufferfRGVs22_ContiguousArrayBufferx_T_'
/usr/bin/ld.gold:
/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-master/buildbot_linux/swift-linux-x86_64/lib/swift_static/linux/libswiftCore.a(Swift.o):
previous definition here
clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)--
Close... (made copyBuffer private)
On Oct 29, 2016, at 6:04 PM, Dave Abrahams via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>>> wrote:
on Sat Oct 29 2016, Alexis <swift-dev-AT-swift.org <http://swift-dev-at-swift.org/> <http://swift-dev-at-swift.org/>> wrote:
On Oct 29, 2016, at 12:13 AM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com> <mailto:spestov@apple.com <mailto:spestov@apple.com>>> wrote:
It will become the default, but not yet, so yeah, you shouldn’t merge anything that only builds
with this flag set.
Can you share the patch that adds private modifiers along with the
linker errors you are seeing? Now would be a good time to sort out
these issues.I’m actually having trouble reproducing this now? I just rebased my
branches onto master and using private/fileprivate on types, aliases,
and functions seems to work perfectly fine (I tried a few things in
Array and Dictionary). Did something interesting just get merged?I suggest you try making and testing a pull request. Often things seem
to work because of the way we build and test locally, but fail in the
full CI environment.On Oct 28, 2016, at 4:16 PM, Alexis Beingessner <abeingessner@apple.com <mailto:abeingessner@apple.com> <mailto:abeingessner@apple.com <mailto:abeingessner@apple.com>> >>>>> <mailto:abeingessner@apple.com <mailto:abeingessner@apple.com> <mailto:abeingessner@apple.com <mailto:abeingessner@apple.com>>>> wrote:
Won't merging anything relying on this flag break the build? Is this going to become the "new"
default soon?
On Oct 28, 2016, at 6:43 PM, Slava Pestov <spestov@apple.com <mailto:spestov@apple.com> <mailto:spestov@apple.com <mailto:spestov@apple.com>> <mailto:spestov@apple.com <mailto:spestov@apple.com> <mailto:spestov@apple.com <mailto:spestov@apple.com>>>> wrote:
On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev >>>>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>>>> wrote:
On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev >>>>>>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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.What do you think Jordan?
MichaelHi Alexis,
You can build the stdlib without sil-serialize-all now by passing a flag to build-script:
./utils/build-script — --swift-stdlib-enable-resilience
Give that a shot and see if it fixes the issues you’re having with ‘private’.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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><https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org>> <mailto:swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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><https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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>--
-Dave_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org> <mailto: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 <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev--
-Dave_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev