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

This is most likely a CMake dependency failure that goes away when you do a clean build. oss-swift-incremental-RA-linux-ubuntu-16_10: undefined symbol: _TFsoi1pu0_Rxs26RangeReplaceableCollection_S_Wx8Iterator7Element_zW_S0_S1__rFTxq__x https://bugs.swift.org/browse/SR-3621 > On Jan 24, 2017,

Re: [swift-corelibs-dev] Asynchronous Operations

Thank you everyone for your comments. Adding willChangeValue(forKey:) and didChangeValue(forKey:) to Operation does solve the problem for me. The Swift 3 code I'm porting from macOS to Linux works correctly when I patch Foundation as Brent suggests. I've opened a PR against

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

> On Jan 24, 2017, at 10:52 PM, Andrew Trick wrote: > > So it looks like the Foundation tests haven’t been run for a few builds. > Taking a wild guess, could this have something to do with mangling Erik? > Unlikely___ swift-dev

Re: [swift-dev] Proposal: Opaque SIL values

> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev > wrote: > > I’m sending out a proposal for fundamentally changing SIL. This work feeds > into generic code optimization, resilience, semantic ARC, and SIL ownership. > This was discussed at length back in

Re: [swift-dev] CI outage tomorrow for upgrade

CI upgrade completed. Note: You will need Xcode 8.3 Beta 1 to be able to build master and swift-3.1-branch. Thanks, Mishal Shah > On Jan 25, 2017, at 11:11 AM, mishal_shah wrote: > > Starting the upgrade process, please avoid triggering PR testing. > > Thanks, >

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 25, 2017, at 9:13 PM, Joe Groff via swift-dev > wrote: > Looks great. One nitpick: > >> Naturally, opaque types must limit some optimizations, such as inlining. > > I don't see how opaque types by themselves prevent inlining. You can inline a > generic into

Re: [swift-dev] Proposal: Opaque SIL values

Looks great. One nitpick: > Naturally, opaque types must limit some optimizations, such as inlining. I don't see how opaque types by themselves prevent inlining. You can inline a generic into another generic, or a function using a resilient type into another function. > This would hide part

Re: [swift-corelibs-dev] [swift-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

Based on the backtrace, I think the code is running into a memory issue with Swift Foundation: https://bugs.swift.org/browse/SR-2485 https://bugs.swift.org/browse/SR-2462 I haven’t seen this in a while - are you able to try running on Swift 3.1 or 3.0.2? Your code seems to work on the IBM

Re: [swift-corelibs-dev] [swift-users] DateFormatter crash on second usage (new instance) on Linux (swift 3.0.1)

We should run those tests with ASAN, I thought I had fixed that with the Sierra merge. Sent from my iPhone > On Jan 25, 2017, at 6:11 PM, Will Stanton via swift-corelibs-dev > wrote: > > Based on the backtrace, I think the code is running into a memory issue

Re: [swift-dev] Proposal: Opaque SIL values

On Jan 24, 2017, at 10:58 PM, Andrew Trick wrote: > > That would come about when the program wants to use the same lvalue for > multiple real values. I don't expect many problems with simple opaque types. > The only way to mutate them is either passing them @inout or

Re: [swift-dev] CI outage tomorrow for upgrade

Starting the upgrade process, please avoid triggering PR testing. Thanks, Mishal Shah > On Jan 24, 2017, at 1:49 PM, Nicole Jacque via swift-dev > wrote: > > Hi All- > > We will have a CI outage for a couple of hours tomorrow starting at 11 > Pacific, in order to