Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (swift 3.0) #131

2016-10-28 Thread Doug Coleman via swift-dev 
:0: error: error parsing input file '/tmp/TemporaryFile.GtuKll' 
(expected top-level entity)
Can't parse Package.swift manifest file because it contains invalid format. Fix 
Package.swift file format and try again.
/home/buildnode/jenkins/workspace/oss-swift-3.0-package-linux-ubuntu-15_10/swiftpm/Tests/PackageLoadingTests/ManifestTests.swift:79:
 error: ManifestTests.testManifestLoading : failed - Unexpected error: 
invalidManifestFormat(nil)

More relevant...
> On Oct 28, 2016, at 6:17 PM, Doug Coleman via swift-dev  
> wrote:
> 
> Filed a jira: https://bugs.swift.org/browse/SR-387 
> 
> 
> 
> Ankit, is this one already fixed in master? I can’t find the bug report for 
> the similar tempfile suffix naming bug.
> 
> Thanks,
> Doug
> 
> 
> Compiling Swift Module 'swift_build' (3 sources)
> Link 
> /home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7/.bootstrap/bin/swift-build
> bootstrap: note: building self-hosted 'swift-build': env 
> SWIFTC=/home/wdillon/build/Ninja-ReleaseAssert/swift-linux-armv7/bin/swiftc 
> SWIFT_BUILD_TOOL=/home/wdillon/build/Ninja-ReleaseAssert/llbuild-linux-armv7/bin/swift-build-tool
>  SWIFT_BUILD_PATH=/home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7 
> SWIFTPM_EMBED_RPATH=$ORIGIN/../lib/swift/linux 
> /home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7/.bootstrap/bin/swift-build
> LLVM ERROR: Program used external function 
> '_TMaC18PackageDescription7Package' which could not be resolved!
> error: ExitStatus(1, 
> ["/home/wdillon/build/Ninja-ReleaseAssert/swift-linux-armv7/bin/swiftc", 
> "--driver-mode=swift", "-I", 
> "/home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7/.bootstrap/lib/swift/pm",
>  "-L", 
> "/home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7/.bootstrap/lib/swift/pm",
>  "-lPackageDescription", "/home/wdillon/swiftpm/Package.swift"])
> bootstrap: error: build failed with exit status 1
> utils/build-script: command terminated with a non-zero exit status 1, aborting
> 
> 
> 
>> On Oct 28, 2016, at 5:59 PM, no-re...@swift.org  
>> wrote:
>> 
>> New issue found!
>> 
>> [FAILURE] oss-swift-3.0-package-linux-ubuntu-15_10 [#131]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-3.0-package-linux-ubuntu-15_10/131/ 
>> 
>> Project: oss-swift-3.0-package-linux-ubuntu-15_10
>> Date of build:   Fri, 28 Oct 2016 17:10:01 -0700
>> Build duration:  49 min
>> Identified problems:
>> 
>> Compile Error: This build failed because of a compile error. Below is a list 
>> of all errors in the build log:
>> Indication 1 
>> 
>> Changes
>> 
>> Commit 0e866a1c48bc66ba023591177973197bfb5871ac by kperry:
>> Ensure directory URL enumerator error handler block is invoked with
>> 
>> edit: stdlib/public/SDK/Foundation/FileManagerThunks.m
>> edit: apinotes/Foundation.apinotes
>> edit: test/1_stdlib/TestFileManager.swift
>> edit: stdlib/public/SDK/Foundation/FileManager.swift
>> 
>> Commit 017e11fce3eeaffd05df45a4461c1dcf5184badb by doug_coleman:
>> [build-script-impl]: Fixes version number on Linux from 3.0 to 3.0.x
>> 
>> edit: utils/build-script-impl
>> 
>> Commit 880f4644e212cb6bce09a1d57a95f7a7ca2e3269 by anders:
>> Bump version to 3.0.2.
>> 
>> edit: Sources/Utility/Versioning.swift
> 
> ___
> 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

Re: [swift-dev] [Swift CI] Build Still Failing: OSS - Swift Package - Ubuntu 15.10 (swift 3.0) #131

2016-10-28 Thread Doug Coleman via swift-dev 
Filed a jira: https://bugs.swift.org/browse/SR-387


Ankit, is this one already fixed in master? I can’t find the bug report for the 
similar tempfile suffix naming bug.

Thanks,
Doug


Compiling Swift Module 'swift_build' (3 sources)
Link 
/home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7/.bootstrap/bin/swift-build
bootstrap: note: building self-hosted 'swift-build': env 
SWIFTC=/home/wdillon/build/Ninja-ReleaseAssert/swift-linux-armv7/bin/swiftc 
SWIFT_BUILD_TOOL=/home/wdillon/build/Ninja-ReleaseAssert/llbuild-linux-armv7/bin/swift-build-tool
 SWIFT_BUILD_PATH=/home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7 
SWIFTPM_EMBED_RPATH=$ORIGIN/../lib/swift/linux 
/home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7/.bootstrap/bin/swift-build
LLVM ERROR: Program used external function '_TMaC18PackageDescription7Package' 
which could not be resolved!
error: ExitStatus(1, 
["/home/wdillon/build/Ninja-ReleaseAssert/swift-linux-armv7/bin/swiftc", 
"--driver-mode=swift", "-I", 
"/home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7/.bootstrap/lib/swift/pm",
 "-L", 
"/home/wdillon/build/Ninja-ReleaseAssert/swiftpm-linux-armv7/.bootstrap/lib/swift/pm",
 "-lPackageDescription", "/home/wdillon/swiftpm/Package.swift"])
bootstrap: error: build failed with exit status 1
utils/build-script: command terminated with a non-zero exit status 1, aborting



> On Oct 28, 2016, at 5:59 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-3.0-package-linux-ubuntu-15_10 [#131]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-3.0-package-linux-ubuntu-15_10/131/ 
> 
> Project:  oss-swift-3.0-package-linux-ubuntu-15_10
> Date of build:Fri, 28 Oct 2016 17:10:01 -0700
> Build duration:   49 min
> Identified problems:
> 
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1 
> 
> Changes
> 
> Commit 0e866a1c48bc66ba023591177973197bfb5871ac by kperry:
> Ensure directory URL enumerator error handler block is invoked with
> 
> edit: stdlib/public/SDK/Foundation/FileManagerThunks.m
> edit: apinotes/Foundation.apinotes
> edit: test/1_stdlib/TestFileManager.swift
> edit: stdlib/public/SDK/Foundation/FileManager.swift
> 
> Commit 017e11fce3eeaffd05df45a4461c1dcf5184badb by doug_coleman:
> [build-script-impl]: Fixes version number on Linux from 3.0 to 3.0.x
> 
> edit: utils/build-script-impl
> 
> Commit 880f4644e212cb6bce09a1d57a95f7a7ca2e3269 by anders:
> Bump version to 3.0.2.
> 
> edit: Sources/Utility/Versioning.swift

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Android: wrong ld (linker) keeps being invoked

2016-10-28 Thread Eric Wing via swift-dev 
On 9/25/16, Brian Gesiak  wrote:
> Eric,
>
> This is definitely something I'd like to improve. I believe karwa's new
> `-tools-directory` option (https://github.com/apple/swift/pull/2912 and
> https://github.com/apple/swift/pull/4543) could take care of this problem.
> If so, we should update docs/Android.md to recommend using that. Could you
> try using that?
>
> As for me, I've found success with the symlink solution up until now. I'm
> not sure why it doesn't work in your case...
>
> I believe that in later versions of Clang, -fuse-ld accepts full paths to
> linkers. So it may work if you have a sufficiently recent version --
> although I haven't tried myself.
>
> - Brian Gesiak
>
>
>
> On Sat, Sep 24, 2016 at 8:26 PM, Eric Wing via swift-dev <
> swift-dev@swift.org> wrote:
>
>> I'm being hit by the problem where the wrong linker is being invoked
>> when trying to build a program with swiftc for Android.
>>
>> The problem seems to already be known and reported here, but the
>> solutions/workarounds don't fully work for me:
>> https://bugs.swift.org/browse/SR-1264
>>
>> The only way I can make this work is by removing/renaming my system
>> installed /usr/bin/ld.gold so the process can't find it.
>>
>>
>> - Changing my PATH so another ld.gold is found first didn't affect
>> things. It looks like it always prefers /usr/bin/ld.gold.
>>
>> - Adding the symlink for /usr/bin/armv7-none-linux-androideabi-ld.gold
>> didn't help (until I removed my /usr/bin/ld.gold
>>
>> - Using the -use-ld=  switch seemed to have absolutely no effect for
>> me. (I tried multiple things like armv7 to find an ld.armv7 and also
>> tried full explicit paths to the real android ld.gold)
>>
>> Any ideas on how to fix this? I don't like having to remove my system
>> ld.gold.
>>
>> Thanks,
>> Eric
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>

After a long delay...

The -tools-directory flag worked.

I also played with -fuse-ld:
I'm invoking swiftc, whicn in turn invokes -fuse-ld behind the scenes.
I didn't try a full path, but I did try renaming the ld tool to
arm-linux-androideabi-ld.gold with the swiftc flag -use-ld. But that
seemed to confuse the process. I'm not sure why. But once I saw there
was a file called ld.gold in a different ndk directory, the
-tools-directory was all I needed.

Thanks,
Eric
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

2016-10-28 Thread Erik Eckstein via swift-dev 

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

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

2016-10-28 Thread Erik Eckstein via swift-dev 

> On Oct 27, 2016, at 1:44 PM, Jordan Rose via swift-dev  
> wrote:
> 
> 
>> On Oct 23, 2016, at 16:13, Michael Gottesman > > wrote:
>> 
>> 
>>> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev 
>>> > 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.

> 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: 
> > 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

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

2016-10-28 Thread Alexis Beingessner via 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  wrote:
> 
> 
>>> On Oct 23, 2016, at 4:13 PM, Michael Gottesman via swift-dev 
>>>  wrote:
>>> 
>>> 
>>> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev 
>>>  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?
>> 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’.
> 
>> 
>>> ___
>>> 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
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-corelibs-dev] Query on NSKeyedArchiver

2016-10-28 Thread Tony Parker via swift-corelibs-dev 
Sorry, this fell off my radar. I’ll test and merge again.

- Tony

> On Oct 27, 2016, at 2:56 AM, Luke Howard  wrote:
> 
> BTW is anything blocking integrating SR-2416?
> 
> https://github.com/apple/swift-corelibs-foundation/pull/574 
> 
> 
> That allows value types to be archived too if they support _ObjectBridgeable 
> (they’ll come back as reference types though).
> 
>> On 27 Oct 2016, at 4:22 AM, Tony Parker via swift-corelibs-dev 
>> > wrote:
>> 
>> 
>>> On Oct 26, 2016, at 10:14 AM, Max Desiatov >> > wrote:
>>> 
>>> Hi Tony,
>>> 
>>> This is very interesting caveat. Is there a plan to get this documented 
>>> anywhere? I haven't seen any documentation for Swift Foundation published 
>>> publicly anywhere akin to how it's done for other APIs at 
>>> https://developer.apple.com/reference/ 
>>> .
>>> 
>>> With best regards, Max.
>> 
>> With respect to the NSObject requirement: It’s really more of a known issue 
>> than a permanent limitation.
>> 
>> To over summarize the situation: NSKeyedArchiver (the Objective-C one) puts 
>> a private category on NSObject and assumes all objects respond to those 
>> messages after that.
>> 
>> We don’t really have documentation for swift-corelibs-foundation beyond what 
>> we can put in our own headerdoc format there. That would be something I 
>> would really appreciate help on if anyone is interested in contributing.
>> 
>> - Tony
>> 
>>> 
 On 26 Oct 2016, at 18:11, Tony Parker via swift-corelibs-dev 
 > wrote:
 
 Hi Sai,
 
 We do have basic support for keyed archiving and unarchiving in 
 swift-corelibs-foundation on Linux. The limitation is that the NSCoding 
 protocol cannot be applied to Swift struct types, only class types. On 
 Darwin, the class also must be a subclass of NSObject. This last 
 limitation may not exist on Linux, but you should be aware that if you 
 encode a non-NSObject subclass on Linux then you would not be able to 
 decode it on Darwin.
 
 - Tony
 
> On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev 
> > 
> wrote:
> 
> Hi Tony,
>  
> From your comments on Pull Request #574 I understand that we cannot 
> archive/un-archive non-NS objects using  NsKeyedArchiver & 
> NSKeyedUnarchiver.I s my understanding correct ..? Does this means that 
> archiving and un-archiving of  swift types is  not supported on Linux  ?
>  
> -Sai Hema
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
 
 ___
 swift-corelibs-dev mailing list
 swift-corelibs-dev@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
 
>>> 
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
> Luke Howard
> web  / facebook 
>  / soundcloud 
>  / spotify 
> 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-dev] Stack dump of the compiler?

2016-10-28 Thread Michael Gottesman via swift-dev 
Are you talking about the prettyprint stack dump?

I think that may have gone away after the recent update to the newer 
llvm/clang. I think there is a bug to look into what happened here, but no one 
has had the time to look into it.

Michael

> On Oct 26, 2016, at 8:53 PM, rintaro ishizaki via swift-dev 
>  wrote:
> 
> > set_target_properties(${swift_binaries} properties ENABLE_EXPORTS 1)  ?
> > I don't know if it's this simple though.
> 
> Yeah, that should work as well.
> But, I'm not sure which tools should be `ENABLE_EXPORT`ed.
> 
> 
> 2016-10-27 3:04 GMT+09:00 Flamedoge  >:
> > Do not add flags to export symbols from executables without the 
> > ENABLE_EXPORTS 
> > 
> >  target property.
> 
> set_target_properties(${swift_binaries} properties ENABLE_EXPORTS 1)  ?
> I don't know if it's this simple though.
> 
> On Tue, Oct 25, 2016 at 8:51 PM, rintaro ishizaki via swift-dev 
> > wrote:
> Hi all,
> I've noticed recent build of swift compiler doesn't show the stack dump on 
> crash.
> 
> Here is the result with October 25, 2016 snapshot.
> https://gist.github.com/rintaro/cb694898821fbbe8b02734862eb69534 
> 
> 
> On macOS, the dump completely doesn't show up.
> On Linux, the dump shows up, but without symbols.
> 
> As for Linux, I figured out that it's because of recent change in 
> CMakeList.txt
> cmake_minimum_required(VERSION 3.4.3)
> Specifically, the policy change of CMP0065
> https://cmake.org/cmake/help/v3.4/policy/CMP0065.html 
> 
> backtrace_symbols_fd() needs symbols exported.
> 
> As for macOS, I'm not sure why.
> 
> I don't know what is the right way to fix this.
> cmake_policy(SET CMP0065 OLD)
> would fix the Linux build but ...
> 
> Any thought?
> 
> ___
> 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

___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

2016-10-28 Thread Jordan Rose via swift-dev 

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

Re: [swift-dev] Swift Class Encoding Standard?

2016-10-28 Thread Jordan Rose via swift-dev 
This is somewhat intentional. While simple names can be encoded hierarchically 
like this, generics make everything more tricky. Consider a demangled name 
"Contacts.Person.Address.PostCode"—in this case not 
only is splitting on "." is no longer a reasonable thing to do, but there's not 
currently a way to get the type for 'Address' with a particular generic 
argument.

The Swift compiler and Foundation teams were a bit at odds here, trying to 
decide whether it would be appropriate to use Swift's current mangling scheme 
for encoded class names, or whether it would be better to pick something else. 
(This is what the Objective-C runtime currently does on Apple platforms, but 
that too could be changed, though we'd have to be careful about 
backward-compatibility.) IIRC at the time we decided it was best to implement 
the minimal thing that handles the common case—top-level non-generic types—and 
worry about the more complicated things later.

Jordan



> On Oct 27, 2016, at 6:54, swizzlr via swift-dev  wrote:
> 
> Swift Foundation has an incomplete implementation of 
> NSClassFromString/NSStringFromClass (link: 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSObjCRuntime.swift#L230-L282
>  
> )
>  due to a lack of a standardised method of encoding nested Swift classes, nor 
> other Swift types.
> 
> I would think that given
> 
> module Contacts
> 
> class Person {
>   struct Address {
>   class Postcode {}
>   }
> }
> 
> Postcode would be encoded as Contacts.Person.Address.Postcode. Since it is 
> not possible to have two different types with the same identifier in the same 
> namespace (i.e. an enum/a class/a struct with the same name at the same 
> declaration level) the encoding would similarly be simple. May I proceed 
> under that assumption or are there ABI stability issues I have yet to 
> consider?
> 
> Tom
> ___
> 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

Re: [swift-corelibs-dev] [swift-dev] Swift Class Encoding Standard?

2016-10-28 Thread Jordan Rose via swift-corelibs-dev 
This is somewhat intentional. While simple names can be encoded hierarchically 
like this, generics make everything more tricky. Consider a demangled name 
"Contacts.Person.Address.PostCode"—in this case not 
only is splitting on "." is no longer a reasonable thing to do, but there's not 
currently a way to get the type for 'Address' with a particular generic 
argument.

The Swift compiler and Foundation teams were a bit at odds here, trying to 
decide whether it would be appropriate to use Swift's current mangling scheme 
for encoded class names, or whether it would be better to pick something else. 
(This is what the Objective-C runtime currently does on Apple platforms, but 
that too could be changed, though we'd have to be careful about 
backward-compatibility.) IIRC at the time we decided it was best to implement 
the minimal thing that handles the common case—top-level non-generic types—and 
worry about the more complicated things later.

Jordan



> On Oct 27, 2016, at 6:54, swizzlr via swift-dev  wrote:
> 
> Swift Foundation has an incomplete implementation of 
> NSClassFromString/NSStringFromClass (link: 
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSObjCRuntime.swift#L230-L282
>  
> )
>  due to a lack of a standardised method of encoding nested Swift classes, nor 
> other Swift types.
> 
> I would think that given
> 
> module Contacts
> 
> class Person {
>   struct Address {
>   class Postcode {}
>   }
> }
> 
> Postcode would be encoded as Contacts.Person.Address.Postcode. Since it is 
> not possible to have two different types with the same identifier in the same 
> namespace (i.e. an enum/a class/a struct with the same name at the same 
> declaration level) the encoding would similarly be simple. May I proceed 
> under that assumption or are there ABI stability issues I have yet to 
> consider?
> 
> Tom
> ___
> swift-dev mailing list
> swift-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Query on NSKeyedArchiver

2016-10-28 Thread Luke Howard via swift-corelibs-dev 
Thanks, SR closed.

> On 28 Oct 2016, at 3:06 AM, Tony Parker  wrote:
> 
> Sorry, this fell off my radar. I’ll test and merge again.
> 
> - Tony
> 
>> On Oct 27, 2016, at 2:56 AM, Luke Howard > > wrote:
>> 
>> BTW is anything blocking integrating SR-2416?
>> 
>> https://github.com/apple/swift-corelibs-foundation/pull/574 
>> 
>> 
>> That allows value types to be archived too if they support _ObjectBridgeable 
>> (they’ll come back as reference types though).
>> 
>>> On 27 Oct 2016, at 4:22 AM, Tony Parker via swift-corelibs-dev 
>>> > wrote:
>>> 
>>> 
 On Oct 26, 2016, at 10:14 AM, Max Desiatov > wrote:
 
 Hi Tony,
 
 This is very interesting caveat. Is there a plan to get this documented 
 anywhere? I haven't seen any documentation for Swift Foundation published 
 publicly anywhere akin to how it's done for other APIs at 
 https://developer.apple.com/reference/ 
 .
 
 With best regards, Max.
>>> 
>>> With respect to the NSObject requirement: It’s really more of a known issue 
>>> than a permanent limitation.
>>> 
>>> To over summarize the situation: NSKeyedArchiver (the Objective-C one) puts 
>>> a private category on NSObject and assumes all objects respond to those 
>>> messages after that.
>>> 
>>> We don’t really have documentation for swift-corelibs-foundation beyond 
>>> what we can put in our own headerdoc format there. That would be something 
>>> I would really appreciate help on if anyone is interested in contributing.
>>> 
>>> - Tony
>>> 
 
> On 26 Oct 2016, at 18:11, Tony Parker via swift-corelibs-dev 
> > 
> wrote:
> 
> Hi Sai,
> 
> We do have basic support for keyed archiving and unarchiving in 
> swift-corelibs-foundation on Linux. The limitation is that the NSCoding 
> protocol cannot be applied to Swift struct types, only class types. On 
> Darwin, the class also must be a subclass of NSObject. This last 
> limitation may not exist on Linux, but you should be aware that if you 
> encode a non-NSObject subclass on Linux then you would not be able to 
> decode it on Darwin.
> 
> - Tony
> 
>> On Oct 26, 2016, at 4:07 AM, Sai Kanduri via swift-corelibs-dev 
>> > 
>> wrote:
>> 
>> Hi Tony,
>>  
>> From your comments on Pull Request #574 I understand that we cannot 
>> archive/un-archive non-NS objects using  NsKeyedArchiver & 
>> NSKeyedUnarchiver.I s my understanding correct ..? Does this means that 
>> archiving and un-archiving of  swift types is  not supported on Linux  ?
>>  
>> -Sai Hema
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
> 
 
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev 
>>> 
>> 
>> Luke Howard
>> web  / facebook 
>>  / soundcloud 
>>  / spotify 
>> 
> 

Luke Howard
web  / facebook 
 / soundcloud 
 / spotify 

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev