[swift-dev] Default implementations from protocols and ABI stability

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(se

Re: [swift-dev] Foundation crashes on Android

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

Re: [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

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 i

Re: [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

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

Re: [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

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

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (swift 4.0) #901

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/TestNS

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

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 dev

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

> 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

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

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

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

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

Re: [swift-dev] DispatchQueue function in Swift 3.0

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

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

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

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

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

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

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

Re: [swift-dev] Linux Foundation test failure

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

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

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

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

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

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

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.

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

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

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

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 w

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

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.o

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

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

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

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

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

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

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

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

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

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

Re: [swift-dev] undefined symbol: _TFC10Foundation8NSNumberg25customPlaygroundQuickLookOs19PlaygroundQuickLook

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

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

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

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

uld 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-corel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 f

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

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

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

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

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

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

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

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

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

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

[swift-dev] Build script and archival steps for the toolchain

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 tha

Re: [swift-dev] [Foundation] Remove/disable availability declarations on OSX? What to do with them?

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 Linu

Re: [swift-dev] Libraries written in Objective-C in Swift 3

> 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

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

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 >

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

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

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

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

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

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

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

> 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

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

> 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

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

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

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

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

Re: [swift-dev] swift_retainCount in CoreFoundation

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

Re: [swift-dev] swift_retainCount in CoreFoundation

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