Re: [swift-dev] swift_retainCount in CoreFoundation

[Philippe Hausler via swift-dev]

> On Dec 22, 2015, at 1:08 PM, Joe Groff via swift-dev  > wrote:
> 
> It looks like the corelibs implementation of CoreFoundation references 
> swift_retainCount in order to implement CFGetRetainCount. Is getting the 
> retain count necessary to CF functionality, or can these functions be removed?

For some reason I was not on this list;
So in response to your query about CF’s usage of CFGetRetainCount - I think we 
can safely forbid that function in the swift version since there is no safe way 
to use it (even CFMachPort is a bit dodgy for it’s usage).

It might take some surgery but I can probably excise that fairly simply.___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] swift_retainCount in CoreFoundation

[Philippe Hausler via swift-dev]

> On Dec 26, 2015, at 12:31 PM, Joe Groff  wrote:
> 
>> 
>> On Dec 25, 2015, at 9:02 PM, Philippe Hausler > > wrote:
>> 
>> > On Dec 22, 2015, at 1:08 PM, Joe Groff via swift-dev > > swift.org > wrote:
>> > 
>> > It looks like the corelibs implementation of CoreFoundation references 
>> > swift_retainCount in order to implement CFGetRetainCount. Is getting the 
>> > retain count necessary to CF functionality, or can these functions be 
>> > removed?
>> 
>> For some reason I was not on this list;
>> So in response to your query about CF’s usage of CFGetRetainCount - I think 
>> we can safely forbid that function in the swift version since there is no 
>> safe way to use it (even CFMachPort is a bit dodgy for it’s usage).
>> 
>> It might take some surgery but I can probably excise that fairly simply.
> 
> That'd be awesome. Thanks Philippe! For CFMachPort's usage, since it's 
> checking for a retainCount of 1, maybe we could use 
> swift_isUniquelyReferenced* instead, which we do need to reliably support for 
> COW.
> 
> -Joe

Actually the method that was being used there is not even compiled on mac 
targets, I was able to safely excise the usage and disallow the function in the 
Swift version of CF. 

I pushed this:
https://github.com/apple/swift-corelibs-foundation/commit/d430c06fe417e285c5b120ccbf1d1082807e3b5c

Which should no longer swift_retainCount in swift-corelibs-foundation builds 
anymore.___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Philippe Hausler via swift-dev]

That is the asset in the compiler that is being hit when the code 
unsafeBitCasts to a c function.

typealias TypeMetadataAccessor = @convention(c) () -> AnyClass?
let accessor = unsafeBitCast(symbol, TypeMetadataAccessor.self) // <— this 
causes the compiler to assert there.

> On Dec 30, 2015, at 10:03 AM, Joe Groff via swift-dev  
> wrote:
> 
> 
>> On Dec 29, 2015, at 9:04 PM, Luke Howard via swift-dev  
>> wrote:
>> 
>> I’m seeing an assertion failure when I try to compile the following on Linux:
>> 
>>  typealias TypeMetadataAccessor = @convention(c) () -> AnyClass?
>> 
>> The assertion failing is:
>> 
>>   assert(getASTContext().LangOpts.EnableObjCInterop ||
>>  *repr != MetatypeRepresentation::ObjC);
>> 
>> in ExistentialMetatypeType::ExistentialMetatypeType(). Commenting it out and 
>> the code compiles and works.
>> 
>> Can someone that understands the compiler suggest the correct fix?
> 
> It looks like you're trying to poke at private runtime metadata structures; 
> please don't do that. What are you trying to do?
> 
> -Joe
> ___
> 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] ExistentialMetatypeType assertion failure on Linux

[Philippe Hausler via swift-dev]

> On Dec 30, 2015, at 3:21 PM, Joe Groff via swift-dev  
> wrote:
> 
> 
>> On Dec 30, 2015, at 2:41 PM, Luke Howard  wrote:
>> 
>> 
 It looks like you're trying to poke at private runtime metadata 
 structures; please don't do that. What are you trying to do?
>>> 
>>> Per our exchange yesterday – implement NSStringFromClass() heuristics for 
>>> NSKeyedArchiver
>> 
>> Sorry I mean NSClassFromString(). I thought indirecting the lookup through 
>> the metadata accessor was at least a little bit less bad than accessing it 
>> directly. :)
> 
> If you're experimenting privately that's OK, but I'd prefer to get the 
> runtime functionality in place before committing anything. We already have 
> our hands full trying to clean up and stabilize the standard library/runtime 
> interfaces.
> 
> -Joe
> ___
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev


Yep and that is why I am holding off on merging this just yet until we can get 
something up and rolling from the stdlib to support this.
For now we could just limit these to the list of hand coded class to string 
conversions and omit the NSStringFromClass/NSClassFromString transform; that 
way we give the stdlib a bit of time to get back on their feet from the break 
and get this code in.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Philippe Hausler via swift-dev]

> On Dec 30, 2015, at 3:55 PM, Luke Howard  wrote:
> 
> 
>> On 31 Dec 2015, at 10:24 AM, Philippe Hausler  wrote:
>> 
>> Yep and that is why I am holding off on merging this just yet until we can 
>> get something up and rolling from the stdlib to support this.
>> For now we could just limit these to the list of hand coded class to string 
>> conversions and omit the NSStringFromClass/NSClassFromString transform; that 
>> way we give the stdlib a bit of time to get back on their feet from the 
>> break and get this code in.
> 
> Your call; I know perfect is the enemy of good enough, but I’m definitely 
> interested in helping get something in stdlib once we decide on what to do 
> re: mangling etc.
> 
> — Luke

I really want to merge in the rest of the coders; so lets go ahead and omit the 
mangling stuff and leave it just as the Foundation classes . That will be a 
huge win in my book, it gives us something that is testable and functional 
enough to do some pretty impressive demonstrations of archiving.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

[Philippe Hausler via swift-dev]

> On Dec 30, 2015, at 6:57 PM, Luke Howard  wrote:
> 
> 
>> On 31 Dec 2015, at 11:25 AM, Luke Howard via swift-dev  
>> wrote:
>> 
>>> I really want to merge in the rest of the coders; so lets go ahead and omit 
>>> the mangling stuff and leave it just as the Foundation classes . That will 
>>> be a huge win in my book, it gives us something that is testable and 
>>> functional enough to do some pretty impressive demonstrations of archiving.
>> 
>> OK, the version I’ve pushed now removes the code that was poking into 
>> runtime structures but still uses dlopen()/the metadata accessor for 
>> NSClassFromString(). Tests verify on OS X and Linux (with compiler fix).
>> 
>> If you want to change this further to use a static mapping table, go for it, 
>> but I’d rather focus my time on getting the appropriate API into stdlib.
> 
> As a compromise how about a:
> 
> * swift_getTypeByName() API that only takes demangled names
> * NSClassFromString()/NSStringFromClass() remain internal and hard fail with 
> nested classes/generics
> * We decide what to do about nested class interop later (is changing the 
> Darwin behaviour something that would even be on the table?)
> 
> — Luke

I think those are all pretty reasonable. The pipeline for changes is 
bi-directional; however it will have to get reviewed by the component owner and 
undergo our process to change API behavior internally. I am fairly certain that 
this is an edge case that hasn’t even been thought of and I would think that 
the rest of the Foundation team will be very apt to nail this down so we don’t 
have to worry about backwards compatibility problems that using the mangled 
name might incur in the future.
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Radar and bugs.swift.org

[Philippe Hausler via swift-dev]

Not to just chime in with a "me too", but if any specifically are about 
Foundation's interface to swift; cross references would be super cool and I 
think it would benefit the community to have them be visible as well.

> On Dec 31, 2015, at 12:03 PM, Joe Groff via swift-dev  
> wrote:
> 
> 
>> On Dec 31, 2015, at 11:47 AM, Keith Smiley via swift-dev 
>>  wrote:
>> 
>> Would it be worthwhile for the swift team if those of us who have created 
>> many swift related radars to copy them over to bugs.swift.org?
> 
> Definitely. If you can spare the extra effort, we'd appreciate cross 
> references between the public and Radar bugs on Jira and Radar too.
> 
> -Joe
> 
> 
> ___
> 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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #3699

[Philippe Hausler via swift-dev]

I pushed fixes for this. The define guards were not fully guarding all 
libdispatch access, but now should be.

Sent from my iPhone

> On Mar 25, 2016, at 1:26 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#3699]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/3699/
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Fri, 25 Mar 2016 13:16:26 -0700
> Build duration:   9 min 51 sec
> 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 bc3abbfc4c9a3a26a80d32692780b25445ad978e by phausler:
> [WIP] an initial implementation of NSOperation, NSBlockOperation and
> 
> edit: Foundation/NSOperation.swift
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] ObjC Interoperability under armv7--linux-gnueabi

[Philippe Hausler via swift-dev]

I would guess that you are emitting with the wrong runtime personality (iirc 
linux defaults to fragile (objc1) GNU objc runtime). You might need to muck 
about with flags, most notably -fobjc-runtime. That being said that path might 
be filled with other issues beyond just the layout differentials. There are 
many potential failure points along the way that would have to be dealt with.

> On Mar 29, 2016, at 1:03 PM, Iliya Trub via swift-dev  
> wrote:
> 
> Dear colleagues
> Ihave built swiftc, libswiftCore.so and other outputs under 
> armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. 
> I linked the simplest swift-application, which creates the instance of custom 
> ObjC-class and call instance-method of it. If somebody interested, I am ready 
> to provide patches, though I know that it can not be included into upstream. 
> But there is not success yet. When I try to run application under 
> armv7l-linux, I get following error:
> 
> Error: Instance variables in _SwiftNativeNSArrayBase overlap superclass 
> NSArray.  Offset of first instance variable, __magic_refCount, is 4.  
> Last instance variable in superclass, _sortedArrayHint, ends at offset 
> 8.  This probably means that you are subclassing aclass from a library, 
> which has changed in a binary-incompatibleway.
> 
> Could anybody explain it? I think, it is explained by some difference between 
> NSArray-implementation in XCode framework and in my opensource library. Is it 
> true? And in what way I can try to fix it? May be, to modify my 
> NSArray-source, but how?
> Thanks in advance for answer.
> ___
> 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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #3818

[Philippe Hausler via swift-dev]

pushed a fix for the test; it is likely that the ICU4C implementation has a 
slight difference between the Apple ICU and the one for linux.

> On Mar 30, 2016, at 4:34 PM, Dmitri Gribenko via swift-dev 
>  wrote:
> 
> Looks like it was https://github.com/apple/swift-corelibs-foundation/pull/286 
> 
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko  >*/
> ___
> 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] Libraries written in Objective-C in Swift 3

[Philippe Hausler via swift-dev]

> On Apr 22, 2016, at 2:03 PM, Mike Berg via swift-dev  
> wrote:
> 
> Hi everyone,
> 
> A question has come up on my project that nobody seems to have an answer for. 
> I was hoping someone here might know:
> 
> On my project, we have a longstanding iOS application that has both objC and 
> swift source files. As is the case for most old apps out there (a few years), 
> we regularly use swift code in objC and vice versa.
> 
> We have been keeping tabs on how Swift has been expanding and we noticed that 
> with Swift 3, the foundation classes will be rewritten in swift. So does this 
> mean that all Swift classes using Foundation automatically start using 
> Foundation written in Swift or is it opt-in? If it’s mandatory, then will 
> libraries dependent on the Objective-C runtime no longer work (i.e. the 
> Alamofire git repo)?

The foundation classes are not being re-written in Swift (for Darwin, the linux 
versions however are). The current proposal on the evolution list is for 
structures, which act in parallel to their reference type counterparts. You can 
still use a reference type where it makes sense, but now you can use a struct 
type where that is desired for a few new types.

One slight change that might have some effect is how the APIs are imported. If 
an API exposed a return type of NSData now it will return a struct Data. That 
can easily be converted back via using `as NSData`.

> 
> Thanks for reading and take care,
> -- 
> Michael Berg
> Technical Analyst
> Solstice Mobile
> (630) 414-6938
> ___
> 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] [Foundation] Remove/disable availability declarations on OSX? What to do with them?

[Philippe Hausler via swift-dev]

Yea, the python build scripts only work on Linux. Before the initial drop I was 
tinkering with making it build both but the Xcode project was just simpler and 
easier to maintain. Either use xcodebuild or use the Xcode IDE instead of the 
ninja builders.

It might be nice one day to unify the Linux and Darwin builds. Per the name of 
Foundation versus SwiftFoundation it sidesteps the potentials of getting 
confused with the system version (since they are not replaceable due to object 
layouts among other things).

Sent from my iPhone

> On May 18, 2016, at 7:24 AM, Karl  wrote:
> 
> To clarify: xctest tries to build Foundation using xcodebuild. Actually, I 
> wonder why it didn’t use xcodebuild the first time. 
> 
> Maybe it should. Maybe that’s the way out of this.
> 
>> On 18 May 2016, at 16:21, Karl  wrote:
>> 
>> OSX 10.11.4, latest Xcode and SDKs.
>> 
>> The Swift compiler is correct here - the CF header has an availability 
>> attribute, but the Foundation symbol doesn’t. Either the Foundation symbol 
>> needs to become less available, or the CF one needs to become more available.
>> 
>> I bypassed it by removing the restrictions from CF, but then I had a problem 
>> at link time: CFRuntime has hardcoded symbols which require the module name 
>> to be “SwiftFoundation”, but it’s defined (right at the top of build.py) as 
>> being “Foundation” (and it’s always been like that since the first commit). 
>> So I don’t know what’s correct - the hardcoded symbols, which say it’s 
>> ‘SwiftFoundation’, or the build script, which has always called it just 
>> ‘Foundation’. I don’t see how it ever compiled and linked on OSX.
>> 
>> That’s not all, either - there’s a clang bug (since version 5 apparently) 
>> which causes it to emit calls to its own ___udivti3 builtin which it can’t 
>> resolve, so you need to add a clang-specific hack to disable 128-bit 
>> division in CFBigNum or it also won't link.
>> 
>> After you do that, you can finally create libFoundation.dylib. 
>> Unfortunately, I tried to build xctest afterwards. If you called the module 
>> ‘Foundation’, it’ll fire up xcodebuild, which fails with those missing 
>> symbols from CFRuntime - this time it wants them to be called 
>> “SwiftFoundation”. So am I supposed to build it as SwiftFoundation? Okay, so 
>> I did that.
>> 
>> I don’t remember if xctest compiled fully (I don’t think it did...), then I 
>> disabled it, and tried to build swiftpm instead. I managed to get most of 
>> the way through that, but then it failed while trying to link ‘swift_build’ 
>> because the link directory /Foundation didn’t exist 
>> (of course it doesn't; it’s called SwiftFoundation now!).
>> 
>> So now I’m just feeling like I opened a can of worms.
>> 
>> 
>>> On 18 May 2016, at 15:56, Philippe Hausler  wrote:
>>> 
>>> We are keeping the CoreFoundation sources in sync with the one that is 
>>> skipped with your SDK and the one running on your system.
>>> 
>>> What version of Mac OS X are you running? What version of the SDK do you 
>>> have? I have a feeling that a combination of those two may be the reason 
>>> for those errors.
>>> 
>>> Sent from my iPhone
>>> 
 On May 18, 2016, at 4:44 AM, Karl via swift-dev  
 wrote:
 
 I’m trying to fix Foundation on OSX (or am I doing something wrong? I was 
 surprised to find it didn’t build)
 
 I’ve run in to a problem, though: swift is telling me that certain APIs 
 are not available:
 
> Foundation/NSNumberFormatter.swift:19:70: error: 'ordinalStyle' is only 
> available on OS X 10.11 or newer
> internal let kCFNumberFormatterOrdinalStyle = 
> CFNumberFormatterStyle.ordinalStyle
>  ^
> Foundation/NSNumberFormatter.swift:19:70: note: add @available attribute 
> to enclosing let
> internal let kCFNumberFormatterOrdinalStyle = 
> CFNumberFormatterStyle.ordinalStyle
>  ^
 
 That’s because the CoreFoundation headers have availability declarations 
 on them.
 It obviously doesn’t make sense for us to keep them (and for the resulting 
 swift Foundation project to inherit them), because we’re building a 
 toolchain and defining all of those symbols, not linking against the 
 system versions.
 
 So in order to build CoreFoundation/Foundation for OSX, we’d need to 
 remove these declarations from the headers. Is there any problem with 
 that? Are they synced to anything at Apple HQ?
 
 Thanks
 
 Karl
 ___
 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] Build script and archival steps for the toolchain

[Philippe Hausler via swift-dev]

I find myself building toolchains very often; with the scripts I am using I am 
immediately installing to the current Xcode toolchain locations and a 
considerable amount of time is being spent in creating a tarball of the 
toolchain (which I don’t really need, but I need all of the steps up-to that 
point).

I was thinking of adding a new flag to skip the tar command; I did not readily 
see a way to skip this step but do all of the rest. Is this something useful 
for others?
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #5568

[Philippe Hausler via swift-dev]

The overlay changes here are for macOS/iOS only. This failure is the spurious 
failure associated with https://bugs.swift.org/browse/SR-1720 which I may have 
a fix for here shortly.

> On Jun 22, 2016, at 1:34 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#5568]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/5568/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Wed, 22 Jun 2016 13:12:26 -0700
> Build duration:   22 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 
> 
> Tests:
> 
> Name: Swift
> Failed: 0 test(s), Passed: 8016 test(s), Total: 8016 test(s)
> 
> Changes
> 
> Commit c1ab18e3e70bf2ed0121896069084ba88a5e6b81 by phausler:
> [gardening] add .self to recent changes for struct Data
> 
> edit: stdlib/public/SDK/Foundation/Data.swift

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #5928

[Philippe Hausler via swift-dev]

Looks like I inadvertently deleted some stuff: will have a fix pushed shortly 

Sent from my iPhone

> On Jun 23, 2016, at 3:25 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5928]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/5928/
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Thu, 23 Jun 2016 15:24:20 -0700
> Build duration:   50 sec
> 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
> Tests:
> 
> Name: Swift
> Failed: 0 test(s), Passed: 8021 test(s), Total: 8021 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 292 test(s), Total: 292 test(s)
> 
> Changes
> 
> Commit 0e43a4d070de00476902e7d3df5c7908e16ef06b by phausler:
> Import the latest String overlay functionality and hoist types
> 
> edit: Foundation/NSString.swift
> edit: Foundation/NSPathUtilities.swift
> edit: Foundation/NSJSONSerialization.swift
> edit: Foundation/NSURLResponse.swift
> edit: TestFoundation/TestNSString.swift
> edit: TestFoundation/TestNSData.swift
> edit: TestFoundation/TestNSTimeZone.swift
> add: Foundation/ExtraStringAPIs.swift
> edit: TestFoundation/TestNSURLResponse.swift
> add: Foundation/NSStringEncodings.swift
> edit: Foundation/NSSwiftRuntime.swift
> edit: TestFoundation/TestNSAttributedString.swift
> edit: TestFoundation/TestNSFileHandle.swift
> edit: TestFoundation/TestNSPipe.swift
> edit: Foundation/NSFileManager.swift
> edit: Foundation/NSXMLDocument.swift
> edit: Foundation/NSScanner.swift
> edit: Foundation/String.swift
> edit: Foundation/NSURL.swift
> edit: Foundation.xcodeproj/project.pbxproj
> edit: build.py
> edit: TestFoundation/TestNSRegularExpression.swift
> edit: TestFoundation/TestNSURL.swift
> edit: TestFoundation/TestNSTask.swift
> edit: TestFoundation/TestNSJSONSerialization.swift
> 
> Commit e6f84e9d4e763ece5d70723006196be64eb49d21 by phausler:
> avoid reading off the end of buffers for parsing numeric fragments in
> 
> edit: TestFoundation/TestNSJSONSerialization.swift
> edit: Foundation/NSJSONSerialization.swift
> 
> Commit f5c2c415d9118ec07811444fbc9a44c39567c7c2 by phausler:
> __CFProphylacticAutofsAccess should not duplicate symbolic information;
> 
> edit: CoreFoundation/Base.subproj/CFInternal.h
> 
> Commit a1906c31b02ffba1f7f2bcc7781ca8bb892b1b1c by phausler:
> re-enable tests in NSURLResponse
> 
> edit: TestFoundation/TestNSURLResponse.swift
> edit: Foundation/NSURLResponse.swift
> 
> Commit f08e2cea138f110ec7e450f4fc8074b2e5f6adf8 by phausler:
> Test against pairity with Darwin, en_GB should use grouping seperators
> 
> edit: TestFoundation/TestNSString.swift
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #5931

[Philippe Hausler via swift-dev]

Pushed a fix to remove the AUMP reference since that is still not available on 
linux

> On Jun 23, 2016, at 4:53 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5931]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/5931/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Thu, 23 Jun 2016 16:49:06 -0700
> Build duration:   4 min 18 sec
> 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 
> 
> Tests: 
> 
> Name: Swift
> Failed: 0 test(s), Passed: 8021 test(s), Total: 8021 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 292 test(s), Total: 292 test(s)
> 
> Changes
> 
> Commit f093cad7f1ed2acc76886b5706fbe6130e656aee by phausler:
> Add back in prefix and suffix methods that were removed from refactoring
> 
> edit: Foundation/NSString.swift

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #5621

[Philippe Hausler via swift-dev]

Fixes pushed for XCTest as well

> On Jun 23, 2016, at 5:09 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#5621]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/5621/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Thu, 23 Jun 2016 16:59:02 -0700
> Build duration:   10 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 e97d911af67561e64811380acc368b12938c22c1 by phausler:
> Excise AUMP reference that was dragged in from the overlay
> 
> edit: Foundation/String.swift

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #5932

[Philippe Hausler via swift-dev]

Fix pushed for the failure in swiftpm as well.

> On Jun 23, 2016, at 4:57 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5932]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/5932/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Thu, 23 Jun 2016 16:56:22 -0700
> Build duration:   1 min 2 sec
> 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 
> 
> Tests:
> 
> Name: Swift
> Failed: 0 test(s), Passed: 8021 test(s), Total: 8021 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 292 test(s), Total: 292 test(s)
> 
> Changes
> 
> Commit e97d911af67561e64811380acc368b12938c22c1 by phausler:
> Excise AUMP reference that was dragged in from the overlay
> 
> edit: Foundation/String.swift

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #5934

[Philippe Hausler via swift-dev]

Yea got that one too, that passes on Darwin builds: it seems like a Linux bug 
in icu from what I can tell

Sent from my iPhone

> On Jun 23, 2016, at 5:50 PM, Michael Ilseman  wrote:
> 
> 
> TestFoundation/TestNSString.swift:633: error: 
> TestNSString.test_initializeWithFormat3 : XCTAssertEqual failed: ("en_GB 
> value is 1000 (42.0)") is not equal to ("en_GB value is 1,000 (42.0)") - 
> 
> 
> 
>> On Jun 23, 2016, at 5:40 PM, no-re...@swift.org wrote:
>> 
>> New issue found!
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5934]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/5934/
>> Project: oss-swift-incremental-RA-linux-ubuntu-15_10
>> Date of build:   Thu, 23 Jun 2016 17:32:22 -0700
>> Build duration:  8 min 31 sec
>> 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
>> Tests: 
>> 
>> Name: Swift
>> Failed: 0 test(s), Passed: 8023 test(s), Total: 8023 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 292 test(s), Total: 292 test(s)
>> 
>> Changes
>> 
>> Commit e9ad55b9d7da8676941d67d82e46886099aa91a1 by milseman:
>> [Core Graphics] Add test case for renamed APIs
>> 
>> add: test/ClangModules/CoreGraphics_test.swift
>> 
>> Commit d2c559d8a80404d623b26f028dd80de0b6bae8a9 by phausler:
>> Correct fallout from latest string refactoring in Foundation
>> 
>> edit: Sources/Utility/File.swift
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #5957

[Philippe Hausler via swift-dev]

Pushed a fix for the swift-corelibs-foundation failure

> On Jun 24, 2016, at 12:23 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#5957]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/5957/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Fri, 24 Jun 2016 12:18:16 -0700
> Build duration:   4 min 53 sec
> 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 
> 
> Tests:
> 
> Name: Swift
> Failed: 0 test(s), Passed: 8026 test(s), Total: 8026 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 292 test(s), Total: 292 test(s)
> 
> Changes
> 
> Commit 16f49dba63af69244d79104422b9f4bbe159785a by fs.output:
> [gardening] Disambiguate the meaning of Expr::getEndLoc() in the doc
> 
> edit: include/swift/AST/Expr.h
> 
> Commit 270dccd568cb90bafc4a4474c8160ed2955f3935 by phausler:
> JSON tests are too complex for the type system to keep up, this test
> 
> edit: TestFoundation/TestNSJSONSerialization.swift
> 
> Commit d780326ea783cdbc893a43b7b3052d071398d609 by phausler:
> @availability flags for versions do not make sense in
> 
> edit: Foundation/String.swift
> edit: Foundation/DateComponents.swift
> 
> Commit 5ec39c3fc25efab0a2e3184d27ee32fa54e2a61e by phausler:
> Add an initial placeholder implementation for Unit/Measurement
> 
> add: Foundation/NSMeasurementFormatter.swift
> add: Foundation/NSMeasurement.swift
> edit: Foundation.xcodeproj/project.pbxproj
> add: Foundation/Unit.swift
> add: Foundation/Measurement.swift
> edit: build.py
> 
> Commit 4cc2794d402565e40203d1a550c56466bd225df8 by phausler:
> Workaround for SR-1897
> 
> edit: TestFoundation/TestNSJSONSerialization.swift
> 
> Commit 4a97e408504427915b2552221c3ac3e99345f40d by phausler:
> update plutil to the latest changes in swift-corelibs-foundation
> 
> edit: Tools/plutil/main.swift

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (master) #4996

[Philippe Hausler via swift-dev]

This is likely from my commit, I will have fixes pushed in a bit.

Sent from my iPhone

> On Jul 5, 2016, at 11:38 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-osx [#4996]
> 
> Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/4996/
> Project:  oss-swift-incremental-RA-osx
> Date of build:Tue, 05 Jul 2016 11:21:43 -0700
> Build duration:   16 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
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1
> Tests:
> 
> Name: Swift
> Failed: 2 test(s), Passed: 8057 test(s), Total: 8059 test(s)
> Failed: Swift.1_stdlib.Reflection_objc.swift
> Failed: Swift.stdlib.String.swift
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 269 test(s), Total: 269 test(s)
> 
> Changes
> 
> Commit d502529fe7d97e5e6ee34dfda63d4ec9e6cc17cd by practicalswift:
> [swiftc] Add 💥 case (😢 → 55, 😀 → 5099) triggered in
> 
> add: validation-test/compiler_crashers/28344-swift-type-transform.swift
> 
> Commit 0db73cb80cab2a89bea1c7db0ff5aa8b6511131e by phausler:
> Revert "[Foundation] Workaround for importer NS_REFINED_FOR_SWIFT
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> 
> Commit 24ff368d4f45f077b2b3b306fe3a3a622d03a786 by phausler:
> [Foundation] Swift3 API naming feedback
> 
> edit: stdlib/public/SDK/Foundation/FileManager.swift
> edit: test/1_stdlib/Reflection_objc.swift
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> edit: apinotes/Foundation.apinotes
> edit: stdlib/public/SDK/Foundation/URL.swift
> edit: test/1_stdlib/NSSetAPI.swift
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 - Long Test (master) #527

[Philippe Hausler via swift-dev]

Working on a fix right now, this was a stale merge

> On Jul 14, 2016, at 8:46 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10-long-test [#527]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10-long-test/527/
>  
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10-long-test
> Date of build:Thu, 14 Jul 2016 08:38:00 -0700
> Build duration:   8 min 3 sec
> 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 
> 
> Tests:
> 
> Name: Swift
> Failed: 0 test(s), Passed: 8062 test(s), Total: 8062 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 226 test(s), Total: 226 test(s)
> 
> Changes
> 
> Commit 941ec1e043c5f29f7fb46be450003ff47379993d by dfarler:
> SwiftRemoteMirror: Add reflection metadata version query API
> 
> edit: stdlib/public/SwiftRemoteMirror/SwiftRemoteMirror.cpp
> edit: tools/swift-reflection-test/swift-reflection-test.c
> edit: include/swift/Reflection/Records.h
> edit: include/swift/SwiftRemoteMirror/SwiftRemoteMirror.h
> 
> Commit fd46a6078532b088ce75289cc9628b3cd3a243c8 by dfarler:
> IRGen: Emit reflection metadata version into Swift binaries
> 
> edit: lib/IRGen/IRGen.cpp
> edit: lib/IRGen/IRGenModule.h
> edit: lib/IRGen/GenReflection.cpp
> edit: test/IRGen/unused.sil
> 
> Commit ae8b2ba0ded42cdf9c2f4e1d0bd38d2a2f3ea8eb by rlevenstein:
> Add a helper method mayHaveOpenedArchetypeOperands to SILInstruction
> 
> edit: include/swift/SIL/SILInstruction.h
> edit: lib/SIL/SILInstruction.cpp
> 
> Commit e9dca6597be09b32c317c94ccb88754f492872da by rlevenstein:
> Serialize SIL basic blocks in the RPOT order
> 
> edit: test/ClangModules/serialization-sil.swift
> edit: test/Serialization/transparent.swift
> edit: lib/Serialization/SerializeSIL.cpp
> edit: test/Serialization/Inputs/def_basic.sil
> 
> Commit fc4fe97332c4e722f658472ae5b2bd461d020ba6 by gregomni:
> Memory management bug fix here for indirect nested enums.
> 
> edit: lib/SILGen/SILGenPattern.cpp
> 
> Commit cfdc9439ced8f3e8a2b14137fc1945199fdfe0af by rlevenstein:
> [sil-cse] Add CSE support for open_existential_ref
> 
> edit: lib/SIL/SILInstruction.cpp
> edit: lib/SILOptimizer/Transforms/CSE.cpp
> edit: test/SILOptimizer/cse.sil
> 
> Commit 779eafda5dd71a42cee9076596596a70dc347f6b by compnerd:
> test: address a number of unused result warnings
> 
> edit: TestFoundation/TestNSString.swift
> edit: TestFoundation/TestNSJSONSerialization.swift
> edit: TestFoundation/TestNSFileManager.swift
> edit: TestFoundation/TestNSNotificationQueue.swift
> edit: TestFoundation/TestNSTask.swift
> edit: TestFoundation/TestNSBundle.swift
> 
> Commit 826371dc04a9b12bca4946d5546d1c13f44fd75b by sakandur:
> Implementing NSURLResponse.copyWithZone
> 
> edit: Foundation/NSURLResponse.swift
> edit: TestFoundation/TestNSURLResponse.swift
> 
> Commit bb42155d10e2a1e728dda3bb0bb70be62d7c00b5 by phausler:
> [NSThread] Updated to match Darwin version (#440)
> 
> edit: TestFoundation/TestNSThread.swift
> edit: Foundation/NSXMLParser.swift
> edit: Foundation/NSThread.swift
> 
> Commit 7de444aa591ad75b2d8d42c59bc07f28361ba7db by phausler:
> Resolved conflicts for NSTask.swift from Bouke/nstask-osx-same-pipe
> 
> edit: Foundation/NSTask.swift

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - OS X (master) #5221

[Philippe Hausler via swift-dev]

NSLock got renamed back to include it’s NS.

> On Jul 15, 2016, at 10:31 AM, Ben Langmuir via swift-dev 
>  wrote:
> 
> These are failing in SwiftPM; and not related to these commits. Did our 
> Foundation get out of sync from SwiftPM?
> 
> /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swiftpm/Sources/Basic/Lock.swift:11:14:
>  error: no such decl in module
> import class Foundation.Lock
>  ^  
> 
> 
> 
>> On Jul 15, 2016, at 10:28 AM, no-re...@swift.org  
>> wrote:
>> 
>> New issue found!
>> 
>> [FAILURE] oss-swift-incremental-RA-osx [#5221]
>> 
>> Build URL:   https://ci.swift.org/job/oss-swift-incremental-RA-osx/5221/ 
>> 
>> Project: oss-swift-incremental-RA-osx
>> Date of build:   Fri, 15 Jul 2016 10:07:30 -0700
>> Build duration:  20 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 c25feab0beccadab28d3af23c5ba04e49de13f12 by blangmuir:
>> [index] Index system ImportDecls even when there is a DeclarationsOnly
>> 
>> edit: lib/Index/IndexingContext.cpp
>> edit: test/Index/index-module.m
>> edit: test/Index/Core/index-with-module.m
>> 
>> Commit d9937b66f53a7e4fe768131a49bcc607cf3bc172 by blangmuir:
>> Attempt to workaround Windows bots after my previous commit
>> 
>> edit: test/Index/index-module.m
>> 
>> Commit d43d77c857995e94c5b782eaebd225f54f93a536 by blangmuir:
>> Remove the new module cache from the index-module test
>> 
>> edit: test/Index/index-module.m
> 
> ___
> 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: 0. OSS - Swift Incremental RA - OS X (master) #5221

[Philippe Hausler via swift-dev]

Hmm that was incomplete:

Is there a reason why a full toolchain build didn’t pick this up? It seems that 
when I built locally everything built just fine and tested ok. My configuration 
that I use to test is a build bot preset that I have modified to have specific 
destinations such that I can automate installing it.

I was under the impression that it built swiftpm by default.

> On Jul 15, 2016, at 4:06 PM, Philippe Hausler via swift-dev 
>  wrote:
> 
> NSLock got renamed back to include it’s NS.
> 
>> On Jul 15, 2016, at 10:31 AM, Ben Langmuir via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> These are failing in SwiftPM; and not related to these commits. Did our 
>> Foundation get out of sync from SwiftPM?
>> 
>> /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swiftpm/Sources/Basic/Lock.swift:11:14:
>>  error: no such decl in module
>> import class Foundation.Lock
>>  ^  
>> 
>> 
>> 
>>> On Jul 15, 2016, at 10:28 AM, no-re...@swift.org 
>>> <mailto:no-re...@swift.org> wrote:
>>> 
>>> New issue found!
>>> 
>>> [FAILURE] oss-swift-incremental-RA-osx [#5221]
>>> 
>>> Build URL:  https://ci.swift.org/job/oss-swift-incremental-RA-osx/5221/ 
>>> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/5221/>
>>> Project:oss-swift-incremental-RA-osx
>>> Date of build:  Fri, 15 Jul 2016 10:07:30 -0700
>>> Build duration: 20 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 
>>> <https://ci.swift.org//job/oss-swift-incremental-RA-osx/5221/consoleFull#-2052600253ee1a197b-acac-4b17-83cf-a53b95139a76>
>>> Changes
>>> 
>>> Commit c25feab0beccadab28d3af23c5ba04e49de13f12 by blangmuir:
>>> [index] Index system ImportDecls even when there is a DeclarationsOnly
>>> 
>>> edit: lib/Index/IndexingContext.cpp
>>> edit: test/Index/index-module.m
>>> edit: test/Index/Core/index-with-module.m
>>> 
>>> Commit d9937b66f53a7e4fe768131a49bcc607cf3bc172 by blangmuir:
>>> Attempt to workaround Windows bots after my previous commit
>>> 
>>> edit: test/Index/index-module.m
>>> 
>>> Commit d43d77c857995e94c5b782eaebd225f54f93a536 by blangmuir:
>>> Remove the new module cache from the index-module test
>>> 
>>> edit: test/Index/index-module.m
>> 
>> ___
>> 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

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - OS X (master) #5221

[Philippe Hausler via swift-dev]

I am working on getting those changes in today for swift-corelibs-foundation, 
along with some of the new value types.

> On Jul 18, 2016, at 10:42 AM, Daniel Dunbar  wrote:
> 
>> 
>> On Jul 15, 2016, at 4:10 PM, Philippe Hausler via swift-dev 
>> mailto:swift-dev@swift.org>> wrote:
>> 
>> Hmm that was incomplete:
>> 
>> Is there a reason why a full toolchain build didn’t pick this up? It seems 
>> that when I built locally everything built just fine and tested ok. My 
>> configuration that I use to test is a build bot preset that I have modified 
>> to have specific destinations such that I can automate installing it.
>> 
>> I was under the impression that it built swiftpm by default.
> 
> I would have expected the buildbot config to, but I don't use the presets 
> myself. Passing `--swiftpm` to the build script definitely should.
> 
> On a related topic, it would be *very* helpful to us if changes like this 
> could land concurrently with the matching support going in on the Linux side, 
> to avoid having to add platform specific shims. 
> 
>  - Daniel
> 
>> 
>>> On Jul 15, 2016, at 4:06 PM, Philippe Hausler via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> NSLock got renamed back to include it’s NS.
>>> 
>>>> On Jul 15, 2016, at 10:31 AM, Ben Langmuir via swift-dev 
>>>> mailto:swift-dev@swift.org>> wrote:
>>>> 
>>>> These are failing in SwiftPM; and not related to these commits. Did our 
>>>> Foundation get out of sync from SwiftPM?
>>>> 
>>>> /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swiftpm/Sources/Basic/Lock.swift:11:14:
>>>>  error: no such decl in module
>>>> import class Foundation.Lock
>>>>  ^  
>>>> 
>>>> 
>>>> 
>>>>> On Jul 15, 2016, at 10:28 AM, no-re...@swift.org 
>>>>> <mailto:no-re...@swift.org> wrote:
>>>>> 
>>>>> New issue found!
>>>>> 
>>>>> [FAILURE] oss-swift-incremental-RA-osx [#5221]
>>>>> 
>>>>> Build URL:
>>>>> https://ci.swift.org/job/oss-swift-incremental-RA-osx/5221/ 
>>>>> <https://ci.swift.org/job/oss-swift-incremental-RA-osx/5221/>
>>>>> Project:  oss-swift-incremental-RA-osx
>>>>> Date of build:Fri, 15 Jul 2016 10:07:30 -0700
>>>>> Build duration:   20 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 
>>>>> <https://ci.swift.org//job/oss-swift-incremental-RA-osx/5221/consoleFull#-2052600253ee1a197b-acac-4b17-83cf-a53b95139a76>
>>>>> Changes
>>>>> 
>>>>> Commit c25feab0beccadab28d3af23c5ba04e49de13f12 by blangmuir:
>>>>> [index] Index system ImportDecls even when there is a DeclarationsOnly
>>>>> 
>>>>> edit: lib/Index/IndexingContext.cpp
>>>>> edit: test/Index/index-module.m
>>>>> edit: test/Index/Core/index-with-module.m
>>>>> 
>>>>> Commit d9937b66f53a7e4fe768131a49bcc607cf3bc172 by blangmuir:
>>>>> Attempt to workaround Windows bots after my previous commit
>>>>> 
>>>>> edit: test/Index/index-module.m
>>>>> 
>>>>> Commit d43d77c857995e94c5b782eaebd225f54f93a536 by blangmuir:
>>>>> Remove the new module cache from the index-module test
>>>>> 
>>>>> edit: test/Index/index-module.m
>>>> 
>>>> ___
>>>> 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 <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] swift-corelibs-foundation failing in object conversion when building on Darwin host

[Philippe Hausler via swift-dev]

With a freshly built toolchain from ToT swift, building ToT 
swift-corelibs-foundation I am getting some very strange failures in the unit 
tests:

Test Suite 'TestNSKeyedArchiver' started at 13:15:01.843
Test Case 'TestNSKeyedArchiver.test_archive_array' started at 13:15:01.843
assertion failed: file 
/Volumes/Users/phausler/Documents/Public/swift/swift-corelibs-foundation/Foundation/NSKeyedArchiver.swift,
 line 23
2016-08-04 13:15:07.650689 TestFoundation[47395:4939580] assertion failed: file 
/Volumes/Users/phausler/Documents/Public/swift/swift-corelibs-foundation/Foundation/NSKeyedArchiver.swift,
 line 23
Current stack trace:

this is being caused by the line:

let classReference = innerDecodingContext.dict["$class"] as? CFKeyedArchiverUID

CFKeyedArchiverUID being AnyObject

and 

class DecodingContext {
fileprivate var dict : Dictionary
…
}

It claims a conditional cast from Any? to AnyObject always succeeds but it is 
giving me an unexpected type later on

Changing to:

let classReference = innerDecodingContext.dict["$class"] as CFKeyedArchiverUID?

Then makes the process no longer crash, however it then fails in an even more 
strange way:


guard let root = try unarchiver.decodeTopLevelObjectOfClasses(classes,
forKey: NSKeyedArchiveRootObjectKey) as? NSObject else {

by expanding that out the decoded object is a NSArray (expected), but that 
cannot be represented as an NSObject?! This isn’t Swift, this is madness!

Perhaps there is some other failure that I am not seeing underpinning this?
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] swift-corelibs-foundation failing in object conversion when building on Darwin host

[Philippe Hausler via swift-dev]

Not post facto of pushing it. I could not in good conscience push such a large 
change without making certain the tests passed. It was extractable but I squash 
merged back onto master to avoid conflicts.

Sent from my iPhone

> On Aug 8, 2016, at 10:42 PM, Luke Howard  wrote:
> 
> Would it be possible to separate the change to NSKeyedUnarchiver in 1d1ddba9 
> into a separate commit?
> 
>> On 5 Aug 2016, at 6:21 AM, Philippe Hausler via swift-dev 
>>  wrote:
>> 
>> With a freshly built toolchain from ToT swift, building ToT 
>> swift-corelibs-foundation I am getting some very strange failures in the 
>> unit tests:
>> 
>> Test Suite 'TestNSKeyedArchiver' started at 13:15:01.843
>> Test Case 'TestNSKeyedArchiver.test_archive_array' started at 13:15:01.843
>> assertion failed: file 
>> /Volumes/Users/phausler/Documents/Public/swift/swift-corelibs-foundation/Foundation/NSKeyedArchiver.swift,
>>  line 23
>> 2016-08-04 13:15:07.650689 TestFoundation[47395:4939580] assertion failed: 
>> file 
>> /Volumes/Users/phausler/Documents/Public/swift/swift-corelibs-foundation/Foundation/NSKeyedArchiver.swift,
>>  line 23
>> Current stack trace:
>> 
>> this is being caused by the line:
>> 
>> let classReference = innerDecodingContext.dict["$class"] as? 
>> CFKeyedArchiverUID
>> 
>> CFKeyedArchiverUID being AnyObject
>> 
>> and 
>> 
>> class DecodingContext {
>>   fileprivate var dict : Dictionary
>>…
>> }
>> 
>> It claims a conditional cast from Any? to AnyObject always succeeds but it 
>> is giving me an unexpected type later on
>> 
>> Changing to:
>> 
>> let classReference = innerDecodingContext.dict["$class"] as 
>> CFKeyedArchiverUID?
>> 
>> Then makes the process no longer crash, however it then fails in an even 
>> more strange way:
>> 
>> 
>> guard let root = try unarchiver.decodeTopLevelObjectOfClasses(classes,
>>   forKey: NSKeyedArchiveRootObjectKey) as? NSObject else 
>> {
>> 
>> by expanding that out the decoded object is a NSArray (expected), but that 
>> cannot be represented as an NSObject?! This isn’t Swift, this is madness!
>> 
>> Perhaps there is some other failure that I am not seeing underpinning this?
>> ___
>> swift-dev mailing list
>> swift-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> --
> www.lukehoward.com
> soundcloud.com/lukehoward
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #7227

[Philippe Hausler via swift-dev]

I have a fix pending for this; will push shortly

> On Aug 9, 2016, at 2:57 PM, Michael Ilseman via swift-dev 
>  wrote:
> 
> 
> Foundation/NSHTTPCookie.swift:262:36: error: 'init(localeIdentifier:)' has 
> been renamed to 'init(identifier:)'
> 
> 
>> On Aug 9, 2016, at 2:54 PM, no-re...@swift.org  
>> wrote:
>> 
>> New issue found!
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#7227]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7227/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-15_10
>> Date of build:   Tue, 09 Aug 2016 14:42:17 -0700
>> Build duration:  12 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 
>> 
>> Tests: 
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8224 test(s), Total: 8224 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
>> 
>> Changes
>> 
>> Commit 2a48e64c4c0ed70633e4b7e0e46be179a6c61f6e by Alex Hoppen:
>> [utils] Python 3 support + tidies in check-incremental
>> 
>> edit: utils/check-incremental
>> 
>> Commit a99ca851df88859f05ad6bdcfedff586ef9d2dbc by harlan:
>> Add empty parens to var-to-function renames
>> 
>> edit: lib/Sema/MiscDiagnostics.cpp
>> edit: test/1_stdlib/Renames.swift
>> edit: test/Sema/availability.swift
>> 
>> Commit ed461ceb09012a708c2aac09ff05aac66d5b1c62 by practicalswift:
>> [swiftc (45 vs. 5156)] Add crasher in
>> 
>> add: 
>> validation-test/compiler_crashers/28392-swift-dependentgenerictyperesolver-resolveselfassociatedtype.swift
>> 
>> Commit 5a7e8f33374a53d5d238fac958d0202751c6b003 by gribozavr:
>> StdlibUnittest: change Minimal~Class types to actually be classes
>> 
>> edit: stdlib/private/StdlibUnittest/MinimalTypes.swift.gyb
>> 
>> Commit 091bd19610c1a90bbc8ccbba478cc152354282d7 by gribozavr:
>> stdlib: add tests for AnyHashable.base, and make test names uniform
>> 
>> edit: validation-test/stdlib/AnyHashable.swift.gyb
>> 
>> Commit 3db584dc452b88c85ae4a4808a2595c45962bcbb by gribozavr:
>> stdlib: AnyHashable: add a fixme
>> 
>> edit: validation-test/stdlib/AnyHashable.swift.gyb
>> 
>> Commit bfadfe37e4288f6ffaa4564f5cfc77d667e1e192 by gribozavr:
>> stdlib: add (XFAIL'ed) tests for errors and NSErrors in AnyHashable
>> 
>> edit: validation-test/stdlib/AnyHashable.swift.gyb
>> 
>> Commit 08c772fdacf2b4ae5ddbba2c7858c2cde0d39a0b by gribozavr:
>> StdlibUnittest: add an `allowBrokenTransitivity` flag to
>> 
>> edit: validation-test/StdlibUnittest/CheckEquatable.swift.gyb
>> edit: stdlib/private/StdlibUnittest/StdlibUnittest.swift.gyb
>> 
>> Commit b162f60070e9ddaf7c703b6b0d006f3caa6c0b8c by gribozavr:
>> runtime: make _SwiftNativeNSError use the Hashable conformance, if
>> 
>> edit: stdlib/public/core/Hashable.swift
>> add: stdlib/public/runtime/SwiftHashableSupport.h
>> edit: stdlib/public/runtime/Casting.cpp
>> edit: stdlib/public/runtime/ErrorObject.mm
>> edit: stdlib/public/runtime/ErrorObjectNative.cpp
>> add: unittests/runtime/Stdlib.cpp
>> edit: stdlib/public/runtime/ErrorObject.h
>> edit: validation-test/stdlib/AnyHashable.swift.gyb
>> edit: unittests/runtime/CMakeLists.txt
>> add: stdlib/public/runtime/AnyHashableSupport.cpp
>> edit: stdlib/public/runtime/CMakeLists.txt
>> delete: stdlib/public/stubs/AnyHashableSupport.cpp
>> edit: stdlib/public/stubs/CMakeLists.txt
>> 
>> Commit 813b556ad28a491e664892eba6b8df68312e17d5 by gribozavr:
>> runtime: hide contents of SwiftValue.h from non-objc runtime build
>> 
>> edit: stdlib/public/runtime/SwiftValue.h
>> 
>> Commit 45ab914bb15f656570ed25e5e60484b77ee2c203 by gribozavr:
>> runtime: make SwiftValue use the Hashable conformance, if available
>> 
>> edit: test/1_stdlib/BridgeIdAsAny.swift.gyb
>> edit: stdlib/public/runtime/SwiftValue.mm
>> 
>> Commit fb52e6dfd803a7e8d7147eb4dd79a831adf4f360 by gribozavr:
>> stdlib: coding style and doc comment fixes
>> 
>> edit: stdlib/public/core/AnyHashable.swift
>> 
>> Commit e6f23fb7d31e710278c7a8790b2702baea3d2d20 by gribozavr:
>> runtime: move two AnyHashable-related entrypoints to
>> 
>> edit: stdlib/public/runtime/Casting.cpp
>> edit: stdlib/public/runtime/SwiftHashableSupport.h
>> 
>> Commit f1ec334fe54303cb158f40c2fd092d4a56dfe853 by gribozavr:
>> stdlib: make AnyHashable(SwiftValue) unbox the value
>> 
>> edit: stdlib/public/runtime/AnyHashableSupport.cpp
>> edit: validation-test/stdlib/AnyHashable.swift.gyb
>> 
>> Commit 8b55c3bb67377c76a130d5bed4ba2ec2e34d54f3 by fs.output:
>> [Sema][NFC] Use the name of the Decl instead of "None"
>> 
>> edit: lib/Sema/TypeCheckPattern.cpp
>> 
>> Commit 5b8a78473ed006b455bd9b3ec915a67195ed0817 by fs.output:
>> stdlib: Fix-it for underestim

Re: [swift-dev] undefined symbol: _TFC10Foundation8NSNumberg25customPlaygroundQuickLookOs19PlaygroundQuickLook

[Philippe Hausler via swift-dev]

Looks like that is a dirty build.

I think we should probably just delete the support in swift-corelibs-foundation 
entirely for now until a stable interface can be decided (and also delete the 
tests for them in swift-corelibs-foundation). 

This can easily be added back in with little effort (and probably updated to 
the latest expositions to match the overlay)

The failure looks like it is linking against an out of date version of 
Foundation that was previously built without the symbols named as expected.

> On Aug 11, 2016, at 4:40 PM, Jordan Rose via swift-dev  
> wrote:
> 
> +Foundation-Michael (and Tony). One more test to update? Problem with clean 
> builds?
> 
> Jordan
> 
> 
>> On Aug 11, 2016, at 16:15, Daniel Dunbar via swift-dev > > wrote:
>> 
>> Is anyone investigating this failure on the CI bots:
>> --
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>>  symbol lookup error: 
>> /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>>  undefined symbol: 
>> _TFC10Foundation8NSNumberg25customPlaygroundQuickLookOs19PlaygroundQuickLook
>> --
>> it has been showing up on and off all day
>> 
>> Latest example:
>>   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7246/console
>>  
>> 
>> 
>>  - Daniel
>> 
>> ___
>> 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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #7396

[Philippe Hausler via swift-dev]

Reverted sadly… seems like we have lib curl installed on ubuntu 14 build 
servers but not ubuntu 15?

> On Aug 18, 2016, at 2:45 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#7396]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7396/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Thu, 18 Aug 2016 14:44:29 -0700
> Build duration:   1 min 20 sec
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8249 test(s), Total: 8249 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit 5fdd36b193cb1f4f97b4e65c0ed5588fafea30c7 by phausler:
> Uplifting PR 299 to work with the latest Foundation
> 
> add: Foundation/NSURLSession/HTTPBodySource.swift
> add: Foundation/NSURLSession/TaskRegistry.swift
> add: Foundation/NSURLSession/libcurlHelpers.swift
> add: Foundation/NSURLSession/HTTPMessage.swift
> add: Foundation/NSURLSession/TransferState.swift
> edit: TestFoundation/main.swift
> add: CoreFoundation/URL.subproj/CFURLSessionInterface.c
> edit: Foundation/NSData.swift
> delete: Foundation/NSURLSession.swift
> edit: CoreFoundation/Base.subproj/ForSwiftFoundationOnly.h
> add: Foundation/NSURLSession/NSURLSessionTask.swift
> add: Foundation/NSURLSession/EasyHandle.swift
> add: Foundation/NSURLSession/NSURLSessionDelegate.swift
> add: Foundation/NSURLSession/NSURLSession.swift
> add: Foundation/NSURLSession/Configuration.swift
> add: Foundation/NSURLSession/NSURLSessionConfiguration.swift
> edit: build.py
> add: TestFoundation/TestNSURLSession.swift
> add: Foundation/NSURLSession/MultiHandle.swift
> add: CoreFoundation/URL.subproj/CFURLSessionInterface.h
> 
> Commit 73ba103ac08a5ee60491793147c92659da9d1630 by phausler:
> Update NSURLSession to be buildable in Xcode and gate all access to
> 
> edit: TestFoundation/TestNSURLSession.swift
> edit: Foundation/NSURLSession/MultiHandle.swift
> edit: Foundation/NSURLSession/HTTPBodySource.swift
> edit: Foundation/NSURLSession/EasyHandle.swift
> edit: Foundation/NSURLSession/NSURLSessionTask.swift
> edit: Foundation/NSURLSession/NSURLSession.swift
> edit: Foundation.xcodeproj/project.pbxproj

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #7401

[Philippe Hausler via swift-dev]

There is a fix pending in a subsequent build for this

https://github.com/apple/swift-package-manager/commit/958267599543d8a6852ab24da12dc98b21fc5463

> On Aug 18, 2016, at 4:01 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#7401]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7401/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Thu, 18 Aug 2016 15:52:31 -0700
> Build duration:   9 min 27 sec
> 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 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8249 test(s), Total: 8249 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit ba3de9ee3b3e08fdd56063c3b16e2465317c6148 by github:
> NSNumber already preserves whether a value was originally boolean.
> 
> edit: stdlib/public/SDK/Foundation/TypePreservingNSNumber.mm
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> edit: validation-test/stdlib/NSNumberBridging.swift.gyb
> 
> Commit 40e532c4b15dcdec6822e193ad8cd6bc12ca7b46 by phausler:
> Revert "Revert "Rename Predicate to NSPredicate""
> 
> edit: Sources/XCTest/Public/XCTestCase+Asynchronous.swift
> edit: Sources/XCTest/Private/XCPredicateExpectation.swift
> 
> Commit 12f9dd2b8916bb120dff52350ceca54417ebb8ae by phausler:
> Revert "Revert "Foundation API Conformance Update: Miscellaneous""
> 
> edit: TestFoundation/TestNSCompoundPredicate.swift
> edit: TestFoundation/TestNSDictionary.swift
> edit: Foundation/NSNumberFormatter.swift
> edit: TestFoundation/TestNSTimer.swift
> edit: Foundation/NSCache.swift
> edit: TestFoundation/TestNSPredicate.swift
> edit: TestFoundation/TestNSFileManager.swift
> edit: TestFoundation/TestNSString.swift
> edit: Foundation/NSPersonNameComponents.swift
> edit: Foundation/NSCompoundPredicate.swift
> edit: Foundation/NSThread.swift
> edit: TestFoundation/TestNSNumberFormatter.swift
> edit: Foundation/NSString.swift
> edit: Foundation/NSTimer.swift
> edit: Foundation/NSError.swift
> edit: Foundation/NSComparisonPredicate.swift
> edit: Foundation/NSFileManager.swift
> edit: Foundation/NSNotification.swift
> edit: Foundation/NSExpression.swift
> edit: Foundation/NSFileHandle.swift
> edit: TestFoundation/TestNSArray.swift
> edit: Foundation/NSMeasurementFormatter.swift
> edit: Foundation/NSPersonNameComponentsFormatter.swift
> edit: Foundation/PersonNameComponents.swift
> edit: Foundation/NSArray.swift
> edit: Foundation/NSUserDefaults.swift
> edit: Foundation/NSPredicate.swift
> edit: TestFoundation/TestNSUserDefaults.swift

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #7403

[Philippe Hausler via swift-dev]

Pushed a fix for this.

> On Aug 18, 2016, at 4:10 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#7403]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7403/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Thu, 18 Aug 2016 16:08:22 -0700
> Build duration:   1 min 46 sec
> 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 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8249 test(s), Total: 8249 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit 0e1c25e15a6ad2e1be477895257f78471d226b67 by lehewjr:
> React to changes coming in swift-corelibs-foundation
> 
> edit: Sources/XCTest/Public/XCTestCase+Asynchronous.swift
> edit: Tests/Functional/Asynchronous/Notifications/Expectations/main.swift
> edit: Tests/Functional/Asynchronous/Notifications/Handler/main.swift
> 
> Commit 6b9e411b63fec0c145d3267db7e6b31fce714817 by phausler:
> Integrate changes made to Thread in swift-corelibs-foundation
> 
> edit: Sources/Basic/Thread.swift
> 
> Commit 1e9db60ff3c5ff4b1b1bcad23265a89ec94e7a4a by lehewjr:
> Swift 3 API Parity:  Data & NSData
> 
> edit: Foundation/NSString.swift
> edit: Foundation/NSFileManager.swift
> edit: TestFoundation/TestNSJSONSerialization.swift
> edit: TestFoundation/TestNSXMLParser.swift
> edit: Foundation/NSFileHandle.swift
> edit: Foundation/NSXMLParser.swift
> edit: TestFoundation/TestNSData.swift
> edit: Foundation/NSXMLDocument.swift
> edit: Foundation/NSConcreteValue.swift
> edit: Foundation/Data.swift
> edit: Foundation/NSData.swift
> 
> Commit fc2566ba0db99f2f3021a30aaa64516b7ae3a2df by lehewjr:
> Data warning fixes identified via linux builds
> 
> edit: TestFoundation/TestNSString.swift
> edit: Foundation/NSData.swift
> edit: TestFoundation/TestNSData.swift
> 
> Commit cd89d7b070d435967a5e829652d7a9398b7c66f8 by lehewjr:
> Remove @escaping and annotate as to why we can
> 
> edit: Foundation/NSData.swift
> 
> Commit efe3245aa0b6c67ade70e04fa67ad999b6b830d9 by lehewjr:
> Swift 3 Darwin API Parity: Notification and friends
> 
> edit: Foundation/NSNotificationQueue.swift
> edit: TestFoundation/TestNSNotificationQueue.swift
> edit: TestFoundation/TestNSNotificationCenter.swift
> edit: Foundation/NSNotification.swift
> edit: Foundation/Notification.swift
> 
> Commit de7fa52a26f33ac3403be2890ebb604547786f80 by lehewjr:
> Swift 3 Darwin Parity: RunLoop, Stream, Port
> 
> edit: Foundation/NSNotificationQueue.swift
> edit: Foundation/NSPort.swift
> edit: TestFoundation/TestNSTimer.swift
> edit: Foundation/NSStream.swift
> edit: Foundation/NSRunLoop.swift
> edit: TestFoundation/TestNSNotificationQueue.swift
> edit: TestFoundation/TestNSStream.swift
> edit: TestFoundation/TestNSRunLoop.swift
> edit: Foundation/NSTask.swift

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

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 15.10 (master) #7404

[Philippe Hausler via swift-dev]

Looks like we are now missing run loop naming updates for XCTest 

Sent from my iPhone

> On Aug 18, 2016, at 4:20 PM, no-re...@swift.org wrote:
> 
> New issue found!
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#7404]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7404/
> Project:  oss-swift-incremental-RA-linux-ubuntu-15_10
> Date of build:Thu, 18 Aug 2016 16:14:22 -0700
> Build duration:   5 min 44 sec
> Identified problems:
> 
> Regression test failed: This build failed because a regression test in the 
> test suite FAILed. Below is a list of all errors:
> Indication 1
> Compile Error: This build failed because of a compile error. Below is a list 
> of all errors in the build log:
> Indication 1
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8249 test(s), Total: 8249 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit b888b0b9ef95d9e1f3ec2eead9128e7766f3b2ef by phausler:
> Correction for building with optional @escaping closure on the init of
> 
> edit: Foundation/NSData.swift
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - Ubuntu 15.10 (master) #1928

[Philippe Hausler via swift-dev]

This should be resolved by the latest change on master for swiftpm 

Sent from my iPhone

> On Aug 18, 2016, at 4:27 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1928]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1928/
> Project:  oss-swift-package-linux-ubuntu-15_10
> Date of build:Thu, 18 Aug 2016 16:03:11 -0700
> Build duration:   24 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 802a95384daa3963e69d7902f265cacd60dffc73 by moiseev:
> [overlay] updating Metal API via apinotes
> 
> edit: apinotes/Metal.apinotes
> 
> Commit 6d3376d50339c4763cc1861261b8c0c4ce85c981 by milseman:
> [id as Any] Coerce keys to rvalues for checking Hashable conformance
> 
> edit: lib/Sema/CSApply.cpp
> edit: test/Constraints/anyhashable-collection-cast.swift
> 
> Commit 3757b36c37ee1565d49271618832396b64d1068e by github:
> [overlay] Nest CallKit enum types within their associated classes
> 
> edit: stdlib/public/SDK/CallKit/CXProviderConfiguration.swift
> edit: apinotes/CallKit.apinotes
> 
> Commit 19e0eb85375c09ccbbbc042f356b1ddd0e755b40 by github:
> Revert "SILPassManager: After a new function is pushed on the stack
> 
> edit: lib/SILOptimizer/PassManager/PassManager.cpp
> edit: test/SILOptimizer/inline_devirtualize_specialize.sil
> edit: lib/SILOptimizer/Transforms/FunctionSignatureOpts.cpp
> edit: include/swift/SILOptimizer/PassManager/PassManager.h
> 
> Commit ba3de9ee3b3e08fdd56063c3b16e2465317c6148 by github:
> NSNumber already preserves whether a value was originally boolean.
> 
> edit: stdlib/public/SDK/Foundation/Foundation.swift
> edit: stdlib/public/SDK/Foundation/TypePreservingNSNumber.mm
> edit: validation-test/stdlib/NSNumberBridging.swift.gyb
> 
> Commit 87942e8d69ed9bc54badb6db0572b34aa8f16c4d by itai:
> Rename Predicate to NSPredicate to match work done in
> 
> edit: Sources/XCTest/Private/XCPredicateExpectation.swift
> edit: Sources/XCTest/Public/XCTestCase+Asynchronous.swift
> 
> Commit c863bfb8991f989847b3a3030d35914ab8c4f861 by github:
> Revert "Rename Predicate to NSPredicate"
> 
> edit: Sources/XCTest/Private/XCPredicateExpectation.swift
> edit: Sources/XCTest/Public/XCTestCase+Asynchronous.swift
> 
> Commit 40e532c4b15dcdec6822e193ad8cd6bc12ca7b46 by phausler:
> Revert "Revert "Rename Predicate to NSPredicate""
> 
> edit: Sources/XCTest/Private/XCPredicateExpectation.swift
> edit: Sources/XCTest/Public/XCTestCase+Asynchronous.swift
> 
> Commit 362a0157967bc28b04313e26fe97cad344a513a3 by phausler:
> [SE-0069] Added UUID value type
> 
> edit: Foundation/NSUUID.swift
> add: Foundation/UUID.swift
> edit: Foundation.xcodeproj/project.pbxproj
> 
> Commit 1ce7984408b0e9de4a778cae4385399ec03da4b5 by phausler:
> Fixed copyright notice for UUID
> 
> edit: Foundation/UUID.swift
> 
> Commit 9c41cb5742988c567c1826282b8f74abc69e2500 by phausler:
> [SE-0069] Importing CUUID on Linux for UUID struct
> 
> edit: Foundation/UUID.swift
> 
> Commit 54bbe6f9e700d82adc865bb9c6a926e8b8267b46 by phausler:
> [SE-0069] Added UUID.swift to build.py
> 
> edit: build.py
> 
> Commit 4a06f4ce4b6180f659dbe757ef7a5659185628cd by phausler:
> Update build.py
> 
> edit: build.py
> 
> Commit 5b332031819c73c6c2ce37fc742e9e89bba31632 by phausler:
> Correct bridging and update to latest syntax changes
> 
> edit: Foundation/UUID.swift
> edit: TestFoundation/TestNSUUID.swift
> edit: Foundation/NSUUID.swift
> 
> Commit c92d8d0d2412737e0e2538800f3779595bcbfb3c by iferber:
> Update NSBinarySearchingOptions to match API exposed by Darwin
> 
> edit: Foundation/NSArray.swift
> edit: TestFoundation/TestNSArray.swift
> 
> Commit 8a4c3e88df7f7ca6f7fa2161887d1c454a932348 by iferber:
> Update NSCache[Delegate] to match API exposed by Darwin Foundation
> 
> edit: Foundation/NSCache.swift
> edit: Foundation/NSString.swift
> 
> Commit a482a157a55e6365ec599129bd9b3f4d1c9cf6e4 by iferber:
> Update FileHandle to match API exposed by Darwin Foundation
> 
> edit: Foundation/NSFileHandle.swift
> 
> Commit d56420ff66bfdacb54c40d3bbacdcfb825c6da8e by iferber:
> Fix compilation issue due to previously order-dependent compilation
> 
> edit: Foundation/NSNotification.swift
> 
> Commit 9e1ed116b11b492e5a8fff9faebac7495b95d9bf by iferber:
> Update NSExpression/NS[Comparison/Compound]Predicate to match API
> 
> edit: Foundation/NSExpression.swift
> edit: Foundation/NSPredicate.swift
> edit: Foundation/NSCompoundPredicate.swift
> edit: TestFoundation/TestNSCompoundPredicate.swift
> edit: TestFoundation/TestNSPredicate.swift
> edit: Foundation/NSComparisonPredicate.swift
> 
> Commit 4e0b18e908c5f21374e23fddde10be24eb030c84 by iferber:
> Eliminate miscellaneous warnings due to merge conflicts/changes
> 
> edit: Foundation/NSError.swift
> edit: Foundation/NSString.swift
> edit: TestFoundation/TestNSString.swift
> edit: TestFoundation/TestNSDictionary.

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #7160

[Philippe Hausler via swift-dev]

This has been a non-deterministic failure: I have a hunch on how to fix it, if 
I cannot in the next 30 min I will disable the test.

> On Aug 25, 2016, at 11:33 AM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7160]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7160/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Thu, 25 Aug 2016 11:19:16 -0700
> Build duration:   14 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 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8271 test(s), Total: 8271 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit fd3db2f72079cee58f006f4c6118fd179927b5ed by phausler:
> Adding s390x to CGFloat (#591)
> 
> edit: Foundation/CGFloat.swift

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #7160

[Philippe Hausler via swift-dev]

https://github.com/apple/swift-corelibs-foundation/pull/597 should resolve the 
issue

> On Aug 25, 2016, at 11:35 AM, Philippe Hausler via swift-dev 
>  wrote:
> 
> This has been a non-deterministic failure: I have a hunch on how to fix it, 
> if I cannot in the next 30 min I will disable the test.
> 
>> On Aug 25, 2016, at 11:33 AM, no-re...@swift.org <mailto:no-re...@swift.org> 
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7160]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7160/ 
>> <https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7160/>
>> Project: oss-swift-incremental-RA-linux-ubuntu-14_04
>> Date of build:   Thu, 25 Aug 2016 11:19:16 -0700
>> Build duration:  14 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 
>> <https://ci.swift.org//job/oss-swift-incremental-RA-linux-ubuntu-14_04/7160/consoleFull#-289045209ee1a197b-acac-4b17-83cf-a53b95139a76>
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8271 test(s), Total: 8271 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
>> 
>> Changes
>> 
>> Commit fd3db2f72079cee58f006f4c6118fd179927b5ed by phausler:
>> Adding s390x to CGFloat (#591)
>> 
>> edit: Foundation/CGFloat.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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #7167

[Philippe Hausler via swift-dev]

This is an un-related timeout on the build. 

This test took 8 seconds to pass

func test_downloadTaskWithURL() {
let urlString = "https://swift.org/LICENSE.txt";
let url = URL(string: urlString)!   
let d = DownloadTask(with: expectation(description: "download task with 
delegate"))
d.run(with: url)
waitForExpectations(timeout: 12)
}

This one caused the tests to timeout which actually caused a hang for 45 
minutes)

func test_downloadTaskWithURLRequest() {
   let urlString = "https://swift.org/LICENSE.txt";
   let urlRequest = NSURLRequest(url: URL(string: urlString)!)  
   let d = DownloadTask(with: expectation(description: "download task with 
delegate"))
   d.run(with: urlRequest)
   waitForExpectations(timeout: 12)
}

@Tony, what do we want to do with these tests? they are validating things but I 
am not certain we can really have tests like this be flaky.

> On Aug 25, 2016, at 2:48 PM, no-re...@swift.org wrote:
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7167]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7167/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Thu, 25 Aug 2016 13:48:19 -0700
> Build duration:   1 hr 0 min
> Identified problems:
> 
> Timeout: This build was marked as FAIL because it timed out.
> Indication 1 
> 
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8274 test(s), Total: 8274 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit 99493a4928c083e42a92b72d71d5ec28a02291cd by github:
> Remove the dep on CUUID for Foundation (#595)
> 
> edit: Foundation/UUID.swift
> 
> Commit 80e0f056716497f30525ae423ab56602595d5b25 by phausler:
> Enable NSLocale keyed archiving unit tests (#596)
> 
> edit: TestFoundation/TestNSKeyedArchiver.swift
> edit: Foundation/NSLocale.swift

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #7176

[Philippe Hausler via swift-dev]

Since this test has been giving us problems I am just going to disable it.

> On Aug 26, 2016, at 11:59 AM, mishal_shah via swift-dev  
> wrote:
> 
> Time out in Foundation test.
> Test Case 'TestURLSession.test_downloadTaskWithURL' started at 16:20:09.237
> 
>> On Aug 26, 2016, at 10:05 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7176]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7176/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-14_04
>> Date of build:   Fri, 26 Aug 2016 09:03:23 -0700
>> Build duration:  1 hr 1 min
>> Identified problems:
>> 
>> Timeout: This build was marked as FAIL because it timed out.
>> Indication 1 
>> 
>> Tests: 
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8275 test(s), Total: 8275 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
>> 
>> Changes
>> 
>> Commit cbbdaf49164550191bcd82539790c4fd3fa3d3f8 by itai:
>> Rename NSOutputStream to OutputStream
>> 
>> edit: Foundation/NSStream.swift
>> edit: TestFoundation/TestNSJSONSerialization.swift
>> edit: Foundation/NSSwiftRuntime.swift
>> edit: Foundation/NSURLSession/NSURLSessionDelegate.swift
>> edit: Foundation/NSURLSession/NSURLSessionTask.swift
>> edit: Foundation/NSURLSession/NSURLSession.swift
>> edit: TestFoundation/TestNSStream.swift
>> edit: Foundation/NSJSONSerialization.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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #7176

[Philippe Hausler via swift-dev]

Disabled that test and a few others that might time out after it in b98f8d67

> On Aug 26, 2016, at 3:41 PM, mishal_shah  wrote:
> 
> Thanks!
> 
>> On Aug 26, 2016, at 3:19 PM, Philippe Hausler > > wrote:
>> 
>> Since this test has been giving us problems I am just going to disable it.
>> 
>>> On Aug 26, 2016, at 11:59 AM, mishal_shah via swift-dev 
>>> mailto:swift-dev@swift.org>> wrote:
>>> 
>>> Time out in Foundation test.
>>> Test Case 'TestURLSession.test_downloadTaskWithURL' started at 16:20:09.237
>>> 
 On Aug 26, 2016, at 10:05 AM, no-re...@swift.org 
  wrote:
 
 [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7176]
 
 Build URL: 
 https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7176/ 
 
 Project:   oss-swift-incremental-RA-linux-ubuntu-14_04
 Date of build: Fri, 26 Aug 2016 09:03:23 -0700
 Build duration:1 hr 1 min
 Identified problems:
 
 Timeout: This build was marked as FAIL because it timed out.
 Indication 1 
 
 Tests: 
 
 Name: Swift(linux-x86_64)
 Failed: 0 test(s), Passed: 8275 test(s), Total: 8275 test(s)
 Name: Swift-Unit
 Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
 
 Changes
 
 Commit cbbdaf49164550191bcd82539790c4fd3fa3d3f8 by itai:
 Rename NSOutputStream to OutputStream
 
 edit: Foundation/NSStream.swift
 edit: TestFoundation/TestNSJSONSerialization.swift
 edit: Foundation/NSSwiftRuntime.swift
 edit: Foundation/NSURLSession/NSURLSessionDelegate.swift
 edit: Foundation/NSURLSession/NSURLSessionTask.swift
 edit: Foundation/NSURLSession/NSURLSession.swift
 edit: TestFoundation/TestNSStream.swift
 edit: Foundation/NSJSONSerialization.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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #7230

[Philippe Hausler via swift-dev]

Those tests have been disabled by 
https://github.com/apple/swift-corelibs-foundation/commit/b98f8d67071b0af39f85c589dfd6cb54ff7c06cd

Sent from my iPhone

> On Aug 31, 2016, at 2:18 PM, Anders Bertelrud via swift-dev 
>  wrote:
> 
> Looks unrelated to the checkins mentioned in this email:
> 
> Test Case 'TestNSHTTPURLResponse.test_MIMETypeAndCharacterEncoding_1' passed 
> (0.0 seconds).
> Test Case 'TestNSHTTPURLResponse.test_MIMETypeAndCharacterEncoding_2' started 
> at 20:30:25.699
> Test Case 'TestNSHTTPURLResponse.test_MIMETypeAndCharacterEncoding_2' passed 
> (0.0 seconds).
> Test Case 'TestNSHTTPURLResponse.test_MIMETypeAndCharacterEncoding_3' started 
> at 20:30:25.699
> Test Case 'TestNSHTTPURLResponse.test_MIMETypeAndCharacterEncoding_3' passed 
> (0.0 seconds).
> Test Suite 'TestNSHTTPURLResponse' passed at 20:30:25.699
>Executed 25 tests, with 0 failures (0 unexpected) in 0.003 (0.003) 
> seconds
> Test Suite 'TestURLSession' started at 20:30:25.699
> Test Case 'TestURLSession.test_dataTaskWithURL' started at 20:30:25.699
> 
> Build timed out (after 45 minutes). Marking the build as failed.
> 
> Build was aborted
> 
> 
> Anders
> 
>> On 2016-08-31, at 14.15, no-re...@swift.org wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7230]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7230/
>> Project: oss-swift-incremental-RA-linux-ubuntu-14_04
>> Date of build:   Wed, 31 Aug 2016 13:03:22 -0700
>> Build duration:  1 hr 12 min
>> Identified problems:
>> 
>> Timeout: This build was marked as FAIL because it timed out.
>> Indication 1
>> Tests: 
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8279 test(s), Total: 8279 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
>> 
>> Changes
>> 
>> Commit 3fa09465c42941444c336acd68092362facd87a1 by nmaccharoli:
>> [stdlib] Move empty check for string concatenation to front
>> 
>> edit: stdlib/public/core/String.swift
>> 
>> Commit 82b37b3e7fed122150dd602e29cae966cebf494d by anders:
>> Check for loose source files in the `Tests` directory (it's a package
>> 
>> edit: Sources/PackageLoading/PackageBuilder.swift
>> edit: Tests/PackageLoadingTests/ConventionTests.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] Linux Foundation test failure

[Philippe Hausler via swift-dev]

TestFoundation has a dependency upon libFoundation.so, however if the naming 
rules of symbols has changed then it probably needs to re-compile everything in 
Foundation. This looks like it had a stale build around.

> On Aug 29, 2016, at 10:43 AM, Dave Abrahams via swift-dev 
>  wrote:
> 
> 
> This appears to be due to some missing dependency information in the
> build system for Foundation's tests.  Some stdlib names not used
> directly by the overlay or tests were changed and now linking fails
> with:
> 
> + env 
> LD_LIBRARY_PATH=//usr//lib/swift/:/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/Foundation:/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/xctest-linux-x86_64:/home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/libdispatch-linux-x86_64/src/.libs:
>  
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>  symbol lookup error: 
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>  undefined symbol: _TWPV10Foundation8IndexSets13IndexableBaseS_
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/utils/build-script:
>  fatal error: command terminated with a non-zero exit status 127, aborting
> 
> Specifically, the symbol in question,
> _TWPV10Foundation8IndexSets13IndexableBaseS_, should be
> _TWPV10Foundation8IndexSets14_IndexableBaseS_
> 
> Does anyone know how to fix it?
> 
> 
> From: no-re...@swift.org 
> Subject: [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 
> 14.04 (master) #7204
> Date: August 29, 2016 at 8:07:08 AM PDT
> To: dabrah...@apple.com 
> Cc: mishal_s...@apple.com 
> Reply-To: swift-dev@swift.org 
> 
> 
> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7204]
> 
> Build URL:
> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7204/ 
> 
> Project:  oss-swift-incremental-RA-linux-ubuntu-14_04
> Date of build:Mon, 29 Aug 2016 07:48:21 -0700
> Build duration:   18 min
> Tests:
> 
> Name: Swift(linux-x86_64)
> Failed: 0 test(s), Passed: 8276 test(s), Total: 8276 test(s)
> Name: Swift-Unit
> Failed: 0 test(s), Passed: 230 test(s), Total: 230 test(s)
> 
> Changes
> 
> Commit 5c13e35f298db8b41fd336f0ffc55db587323c09 by dabrahams:
> [stdlib] Suppress noisy warnings
> 
> edit: stdlib/public/core/Builtin.swift
> edit: stdlib/public/core/CollectionAlgorithms.swift.gyb
> edit: test/Interpreter/repl.swift
> edit: stdlib/public/core/Collection.swift
> edit: stdlib/public/core/ExistentialCollection.swift.gyb
> edit: stdlib/public/core/Indices.swift.gyb
> edit: stdlib/public/core/RandomAccessCollection.swift
> edit: stdlib/public/core/MutableCollection.swift
> edit: stdlib/public/core/HashedCollections.swift.gyb
> edit: stdlib/public/core/Slice.swift.gyb
> edit: stdlib/public/core/BidirectionalCollection.swift
> edit: 
> stdlib/private/StdlibCollectionUnittest/CheckCollectionInstance.swift.gyb
> edit: stdlib/public/SDK/Foundation/Data.swift
> edit: stdlib/public/core/StringInterpolation.swift.gyb
> edit: test/SILOptimizer/prespecialize.swift
> edit: docs/Literals.rst
> edit: stdlib/public/core/UnsafeBufferPointer.swift.gyb
> edit: stdlib/public/core/CompilerProtocols.swift
> edit: validation-test/stdlib/CollectionDiagnostics.swift
> edit: include/swift/AST/DiagnosticsSema.def
> edit: include/swift/AST/KnownProtocols.def
> edit: stdlib/public/core/RangeReplaceableCollection.swift.gyb
> 
> 
> 
> 
> 
> -- 
> -Dave
> ___
> 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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #7287

[Philippe Hausler via swift-dev]

Because Foundation has no information upon the dependency graph for swift; 
perhaps we should just be recompiling everything every single time for 
libFoundation.so. It seems like a waste of CPU cycles but I don’t really see 
any way around it. 

> On Sep 6, 2016, at 2:41 PM, Slava Pestov via swift-dev  
> wrote:
> 
> This error is caused by stale build artifacts:
> 
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>  symbol lookup error: 
> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>  undefined symbol: 
> _TFesRxs22RandomAccessCollectionwx5Indexs10Strideablewx7IndiceszGVs14CountableRangewxS0__wx13IndexDistancezWxS2_11SubSequence7IndicesS4__wxS0_zWxS2_S5_S5_8Iterator7Element_WxS2_S6__zGS3_wxS0__WxS2_S7__zGVs16IndexingIteratorGS3_wxS0___WxS2_S5__zGS3_wxS0__WxS2_S4__zWxS2_S5_S6_S4__WxS2_S0__zWxS2_S5_S5_S7_S8__WxS2_8_Element_zWxS2_S5_S5_S7_S8__WxS0_6Stride_zWxS2_S5_S6_S4__WxS2_S6_S6__zGS3_wxS0__WxS2_S6_S7__zGS9_GS3_wxS0___WxS2_S6_S5__zGS3_wxS0__WxS2_S6_S4__zWxS2_S5_S6_S4__WxS2_S6_S0__zWxS2_S5_S5_S7_S8__WxS2_S6_S10__zWxS2_S5_S5_S7_S8__WxS2_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S5_13IndexDistance_zWxS2_S5_S6_S4__WxS2_S5_S6__zGS3_wxS0__WxS2_S5_S7__zGS9_GS3_wxS0___WxS2_S5_S5__zGS3_wxS0__WxS2_S5_S0__zWxS2_S5_S5_S7_S8__WxS2_S5_S10__zWxS2_S5_S5_S7_S8__WxS2_S6_S6_S7__zGS9_GS3_wxS0___WxS2_S6_S6_S5__zGS3_wxS0__WxS2_S6_S6_S4__zWxS2_S5_S6_S4__WxS2_S6_S6_S0__zWxS2_S5_S5_S7_S8__WxS2_S6_S6_S10__zWxS2_S5_S5_S7_S8__WxS2_S6_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S6_S5_S7__zGS9_GS3_wxS0___WxS2_S6_S5_S5__zGS3_wxS0__WxS2_S6_S5_S0__zWxS2_S5_S5_S7_S8__WxS2_S6_S5_S10__zWxS2_S5_S5_S7_S8__WxS2_S5_S6_S7__zGS9_GS3_wxS0___WxS2_S5_S6_S5__zGS3_wxS0__WxS2_S5_S6_S0__zWxS2_S5_S5_S7_S8__WxS2_S5_S6_S10__zWxS2_S5_S5_S7_S8__WxS2_S5_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S5_S5_S7__zGS9_GS3_wxS0___WxS2_S5_S5_S5__zGS3_wxS0__WxS2_S5_S5_S0__zWxS2_S5_S5_S7_S8__WxS2_S5_S5_S10__zWxS2_S5_S5_S7_S8__WxS2_S6_S6_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S6_S5_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S5_S6_S7_S8__zWxS2_S5_S5_S7_S8__rS_g7indicesGS3_wxS0__
> 
> I changed the mangling and it appears something was not recompiled. Is anyone 
> looking into these issues?
> 
>> On Sep 6, 2016, at 2:06 PM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7287]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7287/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-14_04
>> Date of build:   Tue, 06 Sep 2016 13:48:21 -0700
>> Build duration:  18 min
>> Tests: 
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8283 test(s), Total: 8283 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 296 test(s), Total: 296 test(s)
>> 
>> Changes
>> 
>> Commit 21ad46b3f650166fef63b458b799c70668c24134 by spestov:
>> AST: Replace ArchetypeBuilder's adoptArchetypes flag with generic
>> 
>> edit: lib/Sema/TypeCheckDecl.cpp
>> edit: include/swift/AST/ArchetypeBuilder.h
>> edit: lib/AST/ArchetypeBuilder.cpp
>> edit: lib/Sema/TypeCheckGeneric.cpp
>> edit: lib/Sema/TypeChecker.h
>> edit: lib/AST/ASTContext.cpp
>> 
>> Commit fb347db4fab1fad6a2a78d8e661929c97949e240 by spestov:
>> AST: Add dump() method to Requirement and GenericEnvironment
>> 
>> edit: lib/AST/ASTPrinter.cpp
>> edit: include/swift/AST/Requirement.h
>> edit: lib/AST/ASTDumper.cpp
>> edit: include/swift/AST/GenericEnvironment.h
>> 
>> Commit 247852cf6dd00a998a544bcf0b7e3ef67d929179 by spestov:
>> AST: Remove unused parameter from
>> 
>> edit: include/swift/AST/ProtocolConformance.h
>> edit: include/swift/AST/Substitution.h
>> edit: lib/AST/ProtocolConformance.cpp
>> edit: lib/AST/Substitution.cpp
>> 
>> Commit 798a07a937ff6bbda682ac776ad51df69464323b by spestov:
>> AST: Fix Type::transform() building of GenericSignatures
>> 
>> edit: lib/AST/Type.cpp
>> 
>> Commit fbe95735980414dd4c256437a3069c305e41053d by spestov:
>> AST: Add some utility methods to GenericSignature
>> 
>> edit: lib/AST/GenericEnvironment.cpp
>> edit: lib/AST/GenericSignature.cpp
>> edit: lib/AST/Substitution.cpp
>> edit: lib/AST/Module.cpp
>> edit: include/swift/AST/Substitution.h
>> edit: lib/Sema/CSApply.cpp
>> edit: include/swift/AST/GenericSignature.h
>> 
>> Commit 19c982bcd9994e1bcddf1db95ddfc6ba85ea1b85 by spestov:
>> AST: Add new TypeBase::getSuperclassForDecl()
>> 
>> edit: lib/AST/Type.cpp
>> edit: include/swift/AST/Types.h
>> 
>> Commit c28529315bc75ccebf01ae45d00428e087c59a0c by spestov:
>> AST: Tweak conformance lookup for class-constrained archetypes
>> 
>> edit: lib/AST/Module.cpp
>> 
>> Commit 07790d3e5e79b292cdde7534c5804dd0cec34fd2 by spestov:
>> SILGen: Re-work witness thunk emission a bit
>> 
>> edit: lib/SILGen/SILGenDecl.cpp
>> edit: lib/SILGen/SIL

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 14.04 (master) #7287

[Philippe Hausler via swift-dev]

The graph only looks at deps from Foundation's tree because we have no 
generator for ninja to validate changes against. 

Sent from my iPhone

> On Sep 6, 2016, at 2:52 PM, Slava Pestov  wrote:
> 
> What do you do when the swift module file format changes? Should I bump the 
> module version when something ABI-related changes, even if the serialization 
> format itself didn’t change?
> 
> Slava
> 
>> On Sep 6, 2016, at 2:44 PM, Philippe Hausler  wrote:
>> 
>> Because Foundation has no information upon the dependency graph for swift; 
>> perhaps we should just be recompiling everything every single time for 
>> libFoundation.so. It seems like a waste of CPU cycles but I don’t really see 
>> any way around it. 
>> 
>>> On Sep 6, 2016, at 2:41 PM, Slava Pestov via swift-dev 
>>>  wrote:
>>> 
>>> This error is caused by stale build artifacts:
>>> 
>>> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>>>  symbol lookup error: 
>>> /home/buildnode/disk2/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/buildbot_incremental/foundation-linux-x86_64/TestFoundation/TestFoundation:
>>>  undefined symbol: 
>>> _TFesRxs22RandomAccessCollectionwx5Indexs10Strideablewx7IndiceszGVs14CountableRangewxS0__wx13IndexDistancezWxS2_11SubSequence7IndicesS4__wxS0_zWxS2_S5_S5_8Iterator7Element_WxS2_S6__zGS3_wxS0__WxS2_S7__zGVs16IndexingIteratorGS3_wxS0___WxS2_S5__zGS3_wxS0__WxS2_S4__zWxS2_S5_S6_S4__WxS2_S0__zWxS2_S5_S5_S7_S8__WxS2_8_Element_zWxS2_S5_S5_S7_S8__WxS0_6Stride_zWxS2_S5_S6_S4__WxS2_S6_S6__zGS3_wxS0__WxS2_S6_S7__zGS9_GS3_wxS0___WxS2_S6_S5__zGS3_wxS0__WxS2_S6_S4__zWxS2_S5_S6_S4__WxS2_S6_S0__zWxS2_S5_S5_S7_S8__WxS2_S6_S10__zWxS2_S5_S5_S7_S8__WxS2_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S5_13IndexDistance_zWxS2_S5_S6_S4__WxS2_S5_S6__zGS3_wxS0__WxS2_S5_S7__zGS9_GS3_wxS0___WxS2_S5_S5__zGS3_wxS0__WxS2_S5_S0__zWxS2_S5_S5_S7_S8__WxS2_S5_S10__zWxS2_S5_S5_S7_S8__WxS2_S6_S6_S7__zGS9_GS3_wxS0___WxS2_S6_S6_S5__zGS3_wxS0__WxS2_S6_S6_S4__zWxS2_S5_S6_S4__WxS2_S6_S6_S0__zWxS2_S5_S5_S7_S8__WxS2_S6_S6_S10__zWxS2_S5_S5_S7_S8__WxS2_S6_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S6_S5_S7__zGS9_GS3_wxS0___WxS2_S6_S5_S5__zGS3_wxS0__WxS2_S6_S5_S0__zWxS2_S5_S5_S7_S8__WxS2_S6_S5_S10__zWxS2_S5_S5_S7_S8__WxS2_S5_S6_S7__zGS9_GS3_wxS0___WxS2_S5_S6_S5__zGS3_wxS0__WxS2_S5_S6_S0__zWxS2_S5_S5_S7_S8__WxS2_S5_S6_S10__zWxS2_S5_S5_S7_S8__WxS2_S5_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S5_S5_S7__zGS9_GS3_wxS0___WxS2_S5_S5_S5__zGS3_wxS0__WxS2_S5_S5_S0__zWxS2_S5_S5_S7_S8__WxS2_S5_S5_S10__zWxS2_S5_S5_S7_S8__WxS2_S6_S6_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S6_S5_S7_S8__zWxS2_S5_S5_S7_S8__WxS2_S5_S6_S7_S8__zWxS2_S5_S5_S7_S8__rS_g7indicesGS3_wxS0__
>>> 
>>> I changed the mangling and it appears something was not recompiled. Is 
>>> anyone looking into these issues?
>>> 
 On Sep 6, 2016, at 2:06 PM, no-re...@swift.org wrote:
 
 [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#7287]
 
 Build URL: 
 https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7287/
 Project:   oss-swift-incremental-RA-linux-ubuntu-14_04
 Date of build: Tue, 06 Sep 2016 13:48:21 -0700
 Build duration:18 min
 Tests: 
 
 Name: Swift(linux-x86_64)
 Failed: 0 test(s), Passed: 8283 test(s), Total: 8283 test(s)
 Name: Swift-Unit
 Failed: 0 test(s), Passed: 296 test(s), Total: 296 test(s)
 
 Changes
 
 Commit 21ad46b3f650166fef63b458b799c70668c24134 by spestov:
 AST: Replace ArchetypeBuilder's adoptArchetypes flag with generic
 
 edit: lib/Sema/TypeCheckDecl.cpp
 edit: include/swift/AST/ArchetypeBuilder.h
 edit: lib/AST/ArchetypeBuilder.cpp
 edit: lib/Sema/TypeCheckGeneric.cpp
 edit: lib/Sema/TypeChecker.h
 edit: lib/AST/ASTContext.cpp
 
 Commit fb347db4fab1fad6a2a78d8e661929c97949e240 by spestov:
 AST: Add dump() method to Requirement and GenericEnvironment
 
 edit: lib/AST/ASTPrinter.cpp
 edit: include/swift/AST/Requirement.h
 edit: lib/AST/ASTDumper.cpp
 edit: include/swift/AST/GenericEnvironment.h
 
 Commit 247852cf6dd00a998a544bcf0b7e3ef67d929179 by spestov:
 AST: Remove unused parameter from
 
 edit: include/swift/AST/ProtocolConformance.h
 edit: include/swift/AST/Substitution.h
 edit: lib/AST/ProtocolConformance.cpp
 edit: lib/AST/Substitution.cpp
 
 Commit 798a07a937ff6bbda682ac776ad51df69464323b by spestov:
 AST: Fix Type::transform() building of GenericSignatures
 
 edit: lib/AST/Type.cpp
 
 Commit fbe95735980414dd4c256437a3069c305e41053d by spestov:
 AST: Add some utility methods to GenericSignature
 
 edit: lib/AST/GenericEnvironment.cpp
 edit: lib/AST/GenericSignature.cpp
 edit: lib/AST/Substitution.cpp
 edit: lib/AST/Module.cpp
 edit: include/swift/AST/Substitution.h
 edit: lib/Sema/CSApply.cpp
 edit: include/swift/AST/GenericSignature.h
 
 Commit 19c

Re: [swift-dev] NSXMLNode.swift: error: integer literal overflows when stored into Int

[Philippe Hausler via swift-dev]

The reason for no issue on iOS 32 bit or watchOS is because the value is 
calculated via NSUInteger which does not overflow at the sign bits like Int. 
TBH I think the right way to solve this constant is to just emit the raw value 
directly instead of attempting to emulate c with bitwise or.

Sent from my iPhone

> On Sep 18, 2016, at 2:27 PM, Michael Gottesman  wrote:
> 
> 
>> On Sep 16, 2016, at 4:37 PM, Eric Wing via swift-dev  
>> wrote:
>> 
>> I'm trying to build Swift 3 for Raspberry Pi 2/armv7.
>> 
>> I'm currently hitting a compile error at:
>> 
>> Foundation/NSXMLNode.swift:86:351: error: integer literal '4293918720'
>> overflows when stored into 'Int'.
>> 
>> public static let nodePreserveAll = Options(rawValue:
>> Options([.nodePreserveNamespaceOrder, .nodePreserveAttributeOrder,
>> .nodePreserveEntities, .nodePreservePrefixes, .nodePreserveCDATA,
>> .nodePreserveEmptyElements, .nodePreserveQuotes,
>> .nodePreserveWhitespace, .nodePreserveDTD,
>> .nodePreserveCharacterReferences]).rawValue | UInt(bitPattern:
>> 0xFFF0))
>> 
>> 
>> I'm assuming this is probably related to the fact that the Pi2 (armv7)
>> is 32-bit, though I'm surprised this isn't already seen on iOS 32-bit.
>> What is the appropriate fix?
> 
> +CC Tony/Phillipe.
> 
>> 
>> Thanks,
>> Eric
>> ___
>> 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] DispatchQueue function in Swift 3.0

[Philippe Hausler via swift-dev]

I believe it got renamed to qos:

DispatchQueue.global(qos: .userInteractive).async {

}

etc.


> On Oct 7, 2016, at 6:11 AM, Yue Cui via swift-dev  wrote:
> 
> Does anyone know the equivalent function of DispatchQueue in Swift 3.0?
> 
> Thanks in advance.
> 
> For the DispatchQueue, the swift 3 has changed it's properties.
> 
> The code for swift 2.xx looks like this:
> 
> let priority = DispatchQueue.GlobalQueuePriority.default
>DispatchQueue.global(priority: priority).async {
>// ALL the API processing..
>DispatchQueue.main.async {
>// ALL the UI reload..
>}
>}
> 
> the error messages shown in Swift 3.0 are:
> 'default' was deprecated in iOS 8.0: Use qos attributes instead.
> 'global(priority:)' was deprecated in iOS 8.0.
> ___
> 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 Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #2022

[Philippe Hausler via swift-dev]

That would be new; I have not seen that failure before. the method is quite 
droll - it just calls sin/cos and resets the m values accordingly. 

Did sin/cos change? the values being sent in are reasonable (not at a point it 
would be in any question of the return value)


> On Feb 20, 2017, at 9:18 PM, Jordan Rose via swift-dev  
> wrote:
> 
> Foundation folks, have you seen this before?
> 
> TestFoundation/TestNSAffineTransform.swift:187: error: 
> TestNSAffineTransform.test_Rotation_Radians : XCTAssertEqualWithAccuracy 
> failed: ("10.0") is not equal to ("-10.0") +/- ("0.001") - y (expected: 
> -10.0, was: 10.0): 
> 
> Jordan
> 
>> On Feb 20, 2017, at 12:05, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2022]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2022/ 
>> 
>> Project: oss-swift-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Mon, 20 Feb 2017 11:47:26 -0800
>> Build duration:  17 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 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 8993 test(s), Total: 8993 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 341 test(s), Total: 341 test(s)
>> 
>> Changes
>> 
>> Commit 042e6510c324c699b86e7a8d0d20068b2ee8feb4 by dgregor:
>> [AST] Drop ProtocolDecl's "inherited protocols" list.
>> 
>> edit: test/decl/class/circular_inheritance.swift
>> edit: lib/IRGen/GenProto.cpp
>> delete: 
>> validation-test/compiler_crashers/28599-false-should-have-found-context-by-now.swift
>> edit: include/swift/AST/Decl.h
>> edit: lib/Sema/ITCDecl.cpp
>> edit: lib/Sema/TypeCheckProtocol.cpp
>> edit: lib/IRGen/GenMeta.cpp
>> edit: test/decl/protocol/protocols.swift
>> edit: lib/Sema/TypeCheckDecl.cpp
>> edit: lib/AST/Type.cpp
>> edit: lib/AST/SubstitutionMap.cpp
>> edit: lib/Serialization/Deserialization.cpp
>> delete: 
>> validation-test/compiler_crashers/28604-isinheritedprotocolsvalid.swift
>> edit: lib/IRGen/GenArchetype.cpp
>> add: 
>> validation-test/compiler_crashers_fixed/28599-false-should-have-found-context-by-now.swift
>> edit: lib/AST/LookupVisibleDecls.cpp
>> edit: lib/ClangImporter/ImportDecl.cpp
>> edit: test/SILGen/objc_bridging_any.swift
>> edit: lib/IRGen/GenClass.cpp
>> edit: lib/Sema/TypeChecker.h
>> edit: lib/AST/Decl.cpp
>> edit: lib/Serialization/Serialization.cpp
>> edit: include/swift/SIL/SILWitnessVisitor.h
>> edit: lib/Sema/TypeCheckType.cpp
>> add: 
>> validation-test/compiler_crashers_fixed/28604-isinheritedprotocolsvalid.swift
>> edit: lib/PrintAsObjC/PrintAsObjC.cpp
>> edit: include/swift/Serialization/ModuleFormat.h
>> edit: lib/IRGen/Fulfillment.cpp
>> 
>> Commit 205303aa64579b40d20c8e052d24c46a87d3a552 by blangmuir:
>> Disable round_trip_stdlib.swift temporarily
>> 
>> edit: test/Syntax/round_trip_stdlib.swift
>> 
>> Commit cb5bc1fedf1da72e5cb25e529915cce941ad327d by mgottesman:
>> Disable opaque_values_silgen.swift with a resilient stdlib until I have
>> 
>> edit: test/SILGen/opaque_values_silgen.swift
>> 
>> Commit b50f044c3d646abfe2e3264369b9a9b616ff6886 by github:
>> Disable a part of the Syntax unit tests under no-asserts. (#7644)
>> 
>> edit: unittests/Syntax/TypeSyntaxTests.cpp
> 
> ___
> 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] Marking a function as __attribute__((weak))

[Philippe Hausler via swift-dev]

Is there a way to mark a function in swift (on Linux) to use the same emission 
strategy as weak declarations in c? 

I was to tinkering with some ideas on fixing some poor behavior in 
swift-corelibs-foundation and weak would potentially solve this specific case.

For reference this is the syntax I am interested in (since it is a bit obscure) 
https://en.m.wikipedia.org/wiki/Weak_symbol

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

Re: [swift-dev] Marking a function as __attribute__((weak))

[Philippe Hausler via swift-dev]

> On Mar 6, 2017, at 5:59 PM, Greg Parker  wrote:
> 
> 
>> On Mar 6, 2017, at 5:48 PM, Philippe Hausler via swift-dev 
>>  wrote:
>> 
>> Is there a way to mark a function in swift (on Linux) to use the same 
>> emission strategy as weak declarations in c? 
>> 
>> I was to tinkering with some ideas on fixing some poor behavior in 
>> swift-corelibs-foundation and weak would potentially solve this specific 
>> case.
>> 
>> For reference this is the syntax I am interested in (since it is a bit 
>> obscure) https://en.m.wikipedia.org/wiki/Weak_symbol
> 
> Weak definitions are expensive. What are you trying to do?
> 

I was trying to prototype some fixes for factory pattern initializers. The 
other strategy that I was considering was using hoisting of functions to init 
methods but that didn't seem to work with disparate types. This wasn't really 
intended to be a real solution but more so a proof of concept.

> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] Renamed types (Swift 3/4 Mix-and-Match)

[Philippe Hausler via swift-dev]

I see your conundrum here! Thats definitely a gnarly issue - I would say the 
preferred way seems much more to the C name of the symbol, but that does have a 
problem that might be possible. In your example the swift 4 name was 
Notification.Identifier, that would mean that it is possible for a developer to 
use then the old name somehow. Is this something we should watch out for? 
Specifically I am more so interested if it is something we should watch out for 
overlay development.

Per your idea about the type alias, shouldn’t we have an effective

@availability(swift, obsoleted: 4.0)
typealias NSNotification.Name = Notification.Identifier

To prevent source compatibility issues?

> On Apr 20, 2017, at 16:55, Jordan Rose via swift-dev  
> wrote:
> 
> TLDR: Should we just always import C/ObjC types under their Swift 4 names, 
> and use typealiases in Swift 3 mode?
> 
> ---
> 
> Hi, swift-dev. As my recent PRs have probably indicated, I've been working on 
> the problems that can come up when mixing Swift 3 and Swift 4 code. Most of 
> these problems have to do with C/ObjC APIs that might present themselves 
> differently in Swift 3 and Swift 4, using the "API notes" feature in our 
> downstream branch of Clang, and a good subset of these problems have to do 
> with types getting renamed. (This includes being "renamed" into a member, 
> such as NSNotificationName becoming (NS)Notification.Name in Swift.)
> 
> What's the problem? Well, there are a few. First of all, an API defined in 
> terms of the Swift 3 name should still be callable in Swift 4. As an example, 
> let's pretend NSNotification.Name was going to be renamed 
> NSNotification.Identifier in Swift 4.
> 
> // Swift 3 library
> public func postTestNotification(named name: NSNotification.Name) { … }
> 
> // Swift 4 app
> let id: Notification.Identifier = …
> postTestNotification(named: id) // should work
> 
> This means the reference to "NSNotification.Name" in the library's 
> swiftmodule needs to still be resolvable. This isn't too bad if we leave 
> behind a typealias for 'NSNotification.Name'. I have a reasonable (but too 
> broad) implementation at https://github.com/apple/swift/pull/8737 
> .
> 
> That just leads us to another problem, though: because Swift functions can be 
> overloaded, the symbol name includes the type, and the type has changed. The 
> Swift 3 library exposes a symbol 
> '_T03Lib20postTestNotificationySo14NSNotificationC4NameV5named_tF', but the 
> Swift 4 client expects 
> '_T03Lib20postTestNotificationySo14NSNotificationC10IdentifierV5named_tF'.
> 
> My planned approach to combat this was to use the C name of the type in the 
> mangling, producing 
> '_T03Lib20postTestNotificationySo18NSNotificationNamea5named_tF'. This is 
> prototyped in https://github.com/apple/swift/pull/8871 
> .
> 
> 
> At this point Slava pointed out I was chasing down a lot of issues when 
> there's a much simpler solution for Swift 4: when importing types, always use 
> the Swift 4 name, and use typealiases to handle Swift 3 compatibility. This 
> defines both of the previous issues away, as well as any more that I just 
> haven't thought of yet.
> 
> There are some downsides:
> - We currently keep people from using Swift 4 names in Swift 3 code, and we 
> wouldn't be able to do that, since the actual declaration of the type always 
> needs to be available.
> - We'd probably want to tweak the "aka" printing in diagnostics to not look 
> through these typealiases. That's not hard, though.
> - We can't keep doing this once we have ABI stability. Hopefully framework 
> owners aren't going to continue changing Swift names of types, but we'll 
> probably need to implement my "C name in the mangling" plan anyway, just in 
> case.
> 
> What do people think?
> 
> 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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (swift 4.0) #901

[Philippe Hausler via swift-dev]

Looks like our tolerance is too tight there. We should relax that so that heavy 
CI load does not muck with it too hard.

> On Jun 27, 2017, at 11:39 AM, Mishal Shah via swift-dev  
> wrote:
> 
> Test Case 'TestNSTimer.test_timerRepeats' started at 2017-06-27 13:34:22.178
>  <>TestFoundation/TestNSTimer.swift:62: error: TestNSTimer.test_timerRepeats 
> : XCTAssertEqual failed: ("1498588462.49172") is not equal to 
> ("1498588462.47838") +/- ("0.01") - 
> Test Case 'TestNSTimer.test_timerRepeats' failed (0.4 seconds)
> 
> Thanks,
> Mishal Shah
> 
>> On Jun 27, 2017, at 11:35 AM, no-re...@swift.org  
>> wrote:
>> 
>> [FAILURE] oss-swift-4.0-incremental-RA-linux-ubuntu-16_10 [#901]
>> 
>> Build URL:   
>> https://ci.swift.org/job/oss-swift-4.0-incremental-RA-linux-ubuntu-16_10/901/
>>  
>> 
>> Project: oss-swift-4.0-incremental-RA-linux-ubuntu-16_10
>> Date of build:   Tue, 27 Jun 2017 11:03:11 -0700
>> Build duration:  31 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 
>> 
>> Tests:
>> 
>> Name: Swift(linux-x86_64)
>> Failed: 0 test(s), Passed: 9535 test(s), Total: 9535 test(s)
>> Name: Swift-Unit
>> Failed: 0 test(s), Passed: 433 test(s), Total: 433 test(s)
>> 
>> Changes
>> 
>> Commit 3c4469ba449d59c4096d0c45050bb2a29ab0b1a8 by Pavel Yaskevich:
>> [QoI] Improve contextual error diagnostics related to calls
>> 
>> edit: lib/Sema/CSDiag.cpp
>> edit: lib/Sema/TypeCheckConstraints.cpp
>> edit: test/Constraints/array_literal.swift
>> edit: test/Generics/deduction.swift
>> edit: test/Constraints/fixes.swift
>> edit: test/Serialization/Recovery/typedefs.swift
>> edit: test/Constraints/diagnostics.swift
>> 
>> Commit 597804f8a5c82fdf804f94702d75c1aa00a494a3 by saiHemak:
>> Fix for URLSession redirect does not inherit request timeout
>> 
>> edit: TestFoundation/TestNSURLSession.swift
>> edit: Foundation/NSURLSession/http/HTTPURLProtocol.swift
>> edit: Foundation/NSURLSession/http/EasyHandle.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] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

[Philippe Hausler via swift-dev]

Is there a radar or bugs.swift.org ticket filed on this?

I presume because of the import this is a Darwin thing and not a linux thing.

> On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev 
>  wrote:
> 
> 
>> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev 
>>  wrote:
>> 
>> I've found what I believe is a bug. Though I'm unclear if the bug is in
>> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
>> quite drastically different between the two.
>> 
>> For the code below (and attached):
>> 
>>   import Cocoa
>> 
>>   var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>>   data.removeFirst(4)
>>   let base64 = data.base64EncodedString()
>>   let str = String(bytes: data[0..<2], encoding: .utf8)!
>>   print("Base64: \(base64), String: \(str)")
>> 
>> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
>> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
>> what I expect.
>> 
>> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
>> swift -swift-version 3 ./data-bug.swift). It performs an illegal
>> hardware instruction and crashes. It also does this if I use use the
>> version 4 of the compiler.
>> 
>> Is this a bug? If so where is the bug? Was this always meant to not work
>> and Swift 3.1 just happened to work or is there now an issue in the
>> Swift 3.2 implementation?
> 
> I have not engaged my brain with the particulars of the rest of the email, 
> but high level question: does this happen without optimization? Or does it 
> happen only with optimization?
> 
> Michael
> 
>> ___
>> 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] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

[Philippe Hausler via swift-dev]

I see the issue.. the latest version traps (appropriately so).

let str = String(bytes: data[0..<2], encoding: .utf8)!

The sub-range of the slice you have is incorrectly indexed. Try this out (I am 
presuming this is what you mean):

let str = String(bytes: data[data.startIndex..<(data.startIndex + 2)], 
encoding: .utf8)!

> On Aug 24, 2017, at 11:07 AM, Philippe Hausler  wrote:
> 
> Is there a radar or bugs.swift.org ticket filed on this?
> 
> I presume because of the import this is a Darwin thing and not a linux thing.
> 
>> On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev 
>>  wrote:
>> 
>> 
>>> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev 
>>>  wrote:
>>> 
>>> I've found what I believe is a bug. Though I'm unclear if the bug is in
>>> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
>>> quite drastically different between the two.
>>> 
>>> For the code below (and attached):
>>> 
>>>  import Cocoa
>>> 
>>>  var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>>>  data.removeFirst(4)
>>>  let base64 = data.base64EncodedString()
>>>  let str = String(bytes: data[0..<2], encoding: .utf8)!
>>>  print("Base64: \(base64), String: \(str)")
>>> 
>>> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
>>> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
>>> what I expect.
>>> 
>>> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
>>> swift -swift-version 3 ./data-bug.swift). It performs an illegal
>>> hardware instruction and crashes. It also does this if I use use the
>>> version 4 of the compiler.
>>> 
>>> Is this a bug? If so where is the bug? Was this always meant to not work
>>> and Swift 3.1 just happened to work or is there now an issue in the
>>> Swift 3.2 implementation?
>> 
>> I have not engaged my brain with the particulars of the rest of the email, 
>> but high level question: does this happen without optimization? Or does it 
>> happen only with optimization?
>> 
>> Michael
>> 
>>> ___
>>> 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] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

[Philippe Hausler via swift-dev]

This is expected behaviors of collections and their slices. The previous result 
was a bug.

I agree that collections in general and their slices need more documentation.

Sent from my iPhone

> On Aug 24, 2017, at 11:28 AM, Ryan Lovelett  
> wrote:
> 
> I think your onto it Philippe but then why is it behaving that way?
> 
> I updated my earlier script (attached) and added 2 things.
> 
>   1. print("Start: \(data.startIndex), End: \(data.endIndex), Count: 
> \(data.count)") after the data.removeFirst(4).
>   2. The startIndex offset you suggested.
> 
> It no longer crashes. Hooray!
> 
> Swift 3.1:
> 
> Start: 0, End: 2, Count: 2
> Base64: QWE=, String: Aa
> 
> Swift 3.2:
> 
> Start: 4, End: 6, Count: 2
> Base64: QWE=, String: Aa
> 
> Oh wait. Woah. That's a really subtle change that has some very real 
> consequences.
> 
> Is this expected and/or documented? Because I certainly would not have 
> expected that drastic of a change. I'll obviously need to go read a lot more 
> of the changes between Swift 3.1 and Swift 3.2 if these sorts of changes are 
> in scope.
> 
> 
>> On Thu, Aug 24, 2017, at 02:10 PM, Philippe Hausler wrote:
>> I see the issue.. the latest version traps (appropriately so).
>> 
>> let str = String(bytes: data[0..<2], encoding: .utf8)!
>> 
>> The sub-range of the slice you have is incorrectly indexed. Try this out (I 
>> am presuming this is what you mean):
>> 
>> let str = String(bytes: data[data.startIndex..<(data.startIndex + 2)], 
>> encoding: .utf8)!
>> 
>>> On Aug 24, 2017, at 11:07 AM, Philippe Hausler  wrote:
>>> 
>>> Is there a radar or bugs.swift.org ticket filed on this?
>>> 
>>> I presume because of the import this is a Darwin thing and not a linux 
>>> thing.
>>> 
 On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev 
  wrote:
 
 
> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev 
>  wrote:
> 
> I've found what I believe is a bug. Though I'm unclear if the bug is in
> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
> quite drastically different between the two.
> 
> For the code below (and attached):
> 
>  import Cocoa
> 
>  var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>  data.removeFirst(4)
>  let base64 = data.base64EncodedString()
>  let str = String(bytes: data[0..<2], encoding: .utf8)!
>  print("Base64: \(base64), String: \(str)")
> 
> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
> what I expect.
> 
> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
> swift -swift-version 3 ./data-bug.swift). It performs an illegal
> hardware instruction and crashes. It also does this if I use use the
> version 4 of the compiler.
> 
> Is this a bug? If so where is the bug? Was this always meant to not work
> and Swift 3.1 just happened to work or is there now an issue in the
> Swift 3.2 implementation?
 
 I have not engaged my brain with the particulars of the rest of the email, 
 but high level question: does this happen without optimization? Or does it 
 happen only with optimization?
 
 Michael
 
> ___
> 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] Foundation crashes on Android

[Philippe Hausler via swift-dev]

> On Dec 18, 2017, at 9:13 AM, Geordie J via swift-dev  
> wrote:
> 
> Hello,
> 
> I’m trying to get the latest version of Foundation working on Android. Just 
> looking to see if anyone has seen similar issues on other (esp. 32bit) 
> platforms or on Android itself.
> 
> I made some minor changes: 
> – CoreFoundation/Base.subproj/CFSortFunctions.c to get e.g. 
> __checkint_int32_mul working – the 32bit versions of those macros seem to be 
> undefined (or incorrectly), so I renamed e.g. __check_int32_mul to 
> __checkint_int32_mul etc.
> – Added an #if !defined(__ANDROID__) check around the import of #include 
> .
> – Added #if defined(__ANDROID__)  typedef unsigned short __swift_mode_t; to 
> LibcShims.h in the Swift repo. This is the change I’m least sure about – I 
> have no idea why this is suddenly necessary, or even whether I’m defining the 
> type correctly.
> 
> Other than that everything seems to build fine.
> 
> The issue is I’m getting a signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) in 
> memmove/memcpy if I try something simple like this:
> 
> let nsDate = NSDate()
> print(nsDate)
> 
> /system/lib/libc.so (memcpy+140)
> .../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:653
> .../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:442
> .../swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFData.c:449
> .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1301
> .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:1326
> .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:816
> .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:824
> .../swift-corelibs-foundation/CoreFoundation/NumberDate.subproj/CFTimeZone.c:860
> .../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:878
> .../swift-corelibs-foundation/CoreFoundation/Locale.subproj/CFDateFormatter.c:1052
> .../swift-corelibs-foundation/Foundation/NSDate.swift:116
> 
> Apparently it crashes on a memmove trying to run CFDateFormatterCreate. Has 
> anyone else seen this? Is it possible that memmove isn’t being linked 
> correctly? I’d be grateful for any tips along these lines.


My guess is that the memcpy is getting passed NULL or a bad pointer, can you 
attach gdb to the process? (One trick I have used in the past is to add a small 
C function called as the very first thing after loading the library that hot 
loops until a global is set and then once gdb is attached set the global to the 
value that will let the loop exit).

> 
> 
> libDispatch seems broken too, but this is probably another issue. Running 
> CFRunLoopRun() produces a __HALT trap with no further stack trace. This one 
> is a signal 4 (SIGILL), code 1 (ILL_ILLOPC), which is normally an overflow or 
> unwrapping a nil value. I guess I’ll try to compile a debug version of 
> libdispatch to track this one further.

Again getting gdb in the mix here would be really helpful to understand what is 
going on.

> 
> 
> I’d be grateful for any further info or tips! Thanks :)
> – Geordie
> 
> ___
> 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] Default implementations from protocols and ABI stability

[Philippe Hausler via swift-dev]

Given the tentative ideas already being worked on for ABI stability what would 
be the place that code associated with a default implementation of a method on 
a protocol live?

e.g.

FooKit has some code that is similar to this:

public struct SomeOptions : RawRepresentable {
public private(set) var rawValue: Int
public init(rawValue: Int) { self.rawValue = rawValue }

public static let sensible = SomeOptions(rawValue: 1 << 0)
public static let maybeWillBeBetterLater = SomeOptions(rawValue: 1 << 1)
}

public protocol Somethingable {
func contrive()
func contrive(options: SomeOptions)
}

extension Somethingable {
func contrive() { contrive(options: .sensible) }
}

Then later on in a newer version of FooKit maybeWillBeBetterLater is now MUCH 
better and should be the default option so the code is updated to look like 
this:

public struct SomeOptions : RawRepresentable {
public private(set) var rawValue: Int
public init(rawValue: Int) { self.rawValue = rawValue }

public static let sensible = SomeOptions(rawValue: 1 << 0)
public static let maybeWillBeBetterLater = SomeOptions(rawValue: 1 << 1)
}

public protocol Somethingable {
func contrive()
func contrive(options: SomeOptions)
}

extension Somethingable {
func contrive() { contrive(options: .maybeWillBeBetterLater) }
}

For apps compiled with FooKit when they are run with the new version of FooKit 
do they get the behavior of sensible or maybeWillBeBetterLater? 

Basically this is a question of where will the code for protocol extensions 
that are adopted across module boundaries live?

This interestingly applies to things like Collection and other standard library 
protocols and has some potential drawbacks and benefits from either way of it 
possibly working.

Thanks in advance for indulging my curiosity.
Philippe
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev