[swift-dev] [Swift CI] Build Failure: OSS - Swift Package - OS X (swift 4.0) #485

2017-07-14 Thread no-reply--- via swift-dev
Title: Report [FAILURE] oss-swift-4.0-package-osx [#485] Build URL:https://ci.swift.org/job/oss-swift-4.0-package-osx/485/ Project:oss-swift-4.0-package-osx Date of build:Fri, 14 Jul 2017 13:07:51 -0700 Build duration:2 hr 46 min Changes Commit

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

2017-07-14 Thread Mishal Shah via swift-dev
Workspace cleaned. Thanks, Mishal Shah > On Jul 14, 2017, at 1:30 PM, Ankit Aggarwal wrote: > > Mishal, please clean the swiftpm build folder. > > On Sat, Jul 15, 2017 at 1:58 AM, David Hart via swift-dev > > wrote:

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

2017-07-14 Thread Ankit Aggarwal via swift-dev
Mishal, please clean the swiftpm build folder. On Sat, Jul 15, 2017 at 1:58 AM, David Hart via swift-dev < swift-dev@swift.org> wrote: > This is due to my commit *"Improve the manifest generation”*. I had the > same error when smoke testing and it seems to be caused by a stale cache or >

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

2017-07-14 Thread David Hart via swift-dev
This is due to my commit "Improve the manifest generation”. I had the same error when smoke testing and it seems to be caused by a stale cache or something in LLBuild. Can something be done to clean the build folders? David. > On 14 Jul 2017, at 22:19, no-re...@swift.org wrote: > > [FAILURE]

Re: [swift-dev] Name mangling of subscripts

2017-07-14 Thread John McCall via swift-dev
> On Jul 14, 2017, at 6:41 AM, Alex Hoppen via swift-dev > wrote: > Hi all, > > With a recent change of mine (#9989 > ) subscripts are no longer > represented internally by the identifier "subscript" but by a DeclBaseName > with

Re: [swift-dev] SR-5403 / Memory Optimization Opportunity (Load/Store forwarding)

2017-07-14 Thread Michael Gottesman via swift-dev
> On Jul 12, 2017, at 9:53 AM, Johannes Weiß wrote: > > Hi Michael, > > >> [...] >>> Long story short, I think the RLE actually works for the test case I >>> created. It's even clever enough to see through my invalid function bad() >>> which modified the storage