[swift-dev] @_specialize attribute

I'd like to let people know that I'm introducing an @_specialize(...) function attribute. See https://github.com/apple/swift/pull/1725 . Feedback is welcome. Just keep in mind that for now this is only an internal attribute. It is not yet a language change

Re: [swift-dev] [WIP] New pull request triggers

> On Mar 23, 2016, at 4:26 PM, Mishal Shah via swift-dev > wrote: > > I am currently working on adding new pull request triggers to ci.swift.org > , you might have already seen few of them as we test > them out. This is really exciting... > Following phrases for apple

Re: [swift-dev] [WIP] New pull request triggers

> On Mar 23, 2016, at 5:21 PM, Mishal Shah wrote: > >> Will the smoke tests cover everything run by the incremental builders? > It will be covered by preset buildbot_incremental,tools=RA,stdlib=RA > Ok. That makes sense. I see that the build preset also invokes the tests, but that the increme

Re: [swift-dev] isUniquelyReferenced issues

> On Apr 1, 2016, at 8:43 AM, Joe Groff via swift-dev > wrote: > > >> On Mar 31, 2016, at 11:49 PM, Patrick Pijnappel >> wrote: >> >> The modified version doesn't seem to change any of the results (on -O or >> -Onone). Note that the problem is that it's not uniquely referenced inside >> b

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 9:27 AM, Jordan Rose wrote: > > On the model itself: Responding to your feedback on the model (thanks!). https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst With

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 9:27 AM, Jordan Rose wrote: > > Thoughts on the diff: https://github.com/atrick/swift/tree/unsafeptr_convert > - What was the thought behind putting UnsafeBytePointer in PointerTypeKind? > OpaquePointer isn’t ther

Re: [swift-dev] [RFC] UnsafeBytePointer API for In-Memory Layout

> On May 12, 2016, at 4:03 PM, John McCall via swift-dev > wrote: > >> On May 12, 2016, at 3:21 PM, Joe Groff wrote: >>> On May 12, 2016, at 11:21 AM, John McCall wrote: >>> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev wrote: > On May 12, 2016, at 10:44, Joe Groff

Re: [swift-dev] What do to when stdlib guidelines conflict with proposal?

> On May 12, 2016, at 9:57 PM, Chris Lattner via swift-dev > wrote: > > >> On May 12, 2016, at 9:16 PM, Russ Bishop > > wrote: >> >> >>> On May 12, 2016, at 8:33 AM, Joe Groff >> > wrote: >>> >>> We might want to wait till we review Andy's U

Re: [swift-dev] Implementation of swift's value types

> On Jul 14, 2016, at 12:39 PM, Johannes Neubauer via swift-dev > wrote: > > Dear Devs, > > I saw the WWDC 2016 video [Understanding Swift Performance][0] as well as > some others regarding value types in swift of WWDC2015. I think there are a > few ambiguities which make it hard both to dec

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

Does anyone have permission to clear this workspace? If I don’t hear back soon I’ll probably have to make a dummy checkin the overlay… -Andy > On Jul 15, 2016, at 1:54 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-osx [#5225] > > Build URL:https

Re: [swift-dev] Implementation of swift's value types

> On Jul 15, 2016, at 9:25 AM, Johannes Neubauer via swift-dev > wrote: > > Is there some documentation of the current implementation of Existential > Container, Protocol Witness Table, and co.? Where do I find it? Arnold’s slides are the best I’ve seen! There are some internal details here:

[swift-dev] 1_stdlib/NSSetAPI.swift fails verifying open archetypes

Roman, This has been failing since July 14 (although the most recent build hit a linker error first). Do you want to try fixing it or can you revert? 1_stdlib/NSSetAPI.swift SIL verification failed: Opened archetype should be registered in SILFunction: Def https://ci.swift.org/job/oss-swift_to

[swift-dev] OSS Swift CI, test-simulator fails to build

Can someone figure out why this bot is failing to build now? https://ci.swift.org/job/oss-swift_tools-RA_stdlib-RDA_test-simulator/1737/consoleFull#-1586822805ee1a197b-acac-4b17-83cf-a53b95139a76 ld: library not found for -lswiftCoreMedia for architecture arm64 clang: error: linker command failed

[swift-dev] swift-ci broken

The swift-ci tests have been regularly failing for the past several days. That makes it impossible to make progress for anyone who is trying to gate their own changes on pull request testing or even rely on local testing on trunk. I thunk swift-ci would work if everyone followed some minimal sta

[swift-dev] Reflection/typeref_lowering.swift' FAILED (but not on Swift CI)

Has anyone else seen this failure on darwin building the latest github/master? commit d78012b03feaa5c946fd7d5254ff9492457f1874 (HEAD -> master, public/master) TEST 'Swift :: Reflection/typeref_lowering.swift' FAILED /s/sptr/swift/test/Reflection/typeref_l

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

Slava, This started failing after your commit: https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6699/ Andy > On Jul 22, 2016, at 4:15 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILUR

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

I disabled the test and filed: SILOptimizer/swap_refcnt.swift failes after noreturn -> Never changes -Andy > On Jul 22, 2016, at 4:27 PM, Andrew Trick via swift-dev > wrote: > > Slava, > > This started failing after your commit: > https://ci.swift.org/job/oss-sw

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

I reverted the test cases changes that caused this, so hopefully Swift CI will start to clear up. -Andy > On Jul 23, 2016, at 7:17 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-osx [#5442] > > Build URL:https://ci.swift.org/job/oss-swift-incremen

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

/Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/swiftpm/Sources/Basic/OutputByteStream.swift:475:47: error: adjacent operators are in non-associative precedence group 'DefaultPrecedence' stream <<< Format.asJSON(key) <<< ":" <<< Format.asJSON(value)

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

CoreFoundation changes crossed paths with UnsafeRawPointer changes. I’m fixing those cases now. -Andy > On Jul 26, 2016, at 3:16 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6862] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA

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

I already checked in a corelibs-foundation fix for this one (conflicting simultaneous commits): Foundation/NSJSONSerialization.swift:164:33: error: cannot invoke initializer for type 'UnsafeMutablePointer' with an argument list of type '(UnsafeRawPointer)' return stream.write(Unsafe

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

And this should be fixed on the next build. -Andy > On Jul 26, 2016, at 3:39 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#6530] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6530/ >

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

I can reproduce this one... /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-15_10/swift/validation-test/stdlib/MicroStdlib/Inputs/Swift.swift:35:10: error: broken standard library: missing builtin precedence group 'AssignmentPrecedence' self = 0 ^ But can’t

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

This was a conflicting commit that I fixed. -Andy > On Jul 26, 2016, at 5:10 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-package-linux-ubuntu-14_04 [#1787] > > Build URL: > https://ci.swift.org/job/oss-swift-package-linux-ubuntu-14_04/1787/ >

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

Phillipe, do you know if these have been fixed yet? -Andy Foundation/NSURLResponse.swift:372:38: error: value of optional type 'UnicodeScalar?' not unwrapped; did you mean to use '!' or '?'? case (.nonQuoted(let s), separator): ^

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

This is Xin’s. -Andy > On Jul 26, 2016, at 5:38 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1777] > > Build URL: > https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1777/ >

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

Mishal, Can you tell me what happened here? -Andy > On Jul 27, 2016, at 9:57 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#5519] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/5519/ >

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

compiler crash > > >> On Jul 27, 2016, at 9:59 AM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Mishal, >> >> Can you tell me what happened here? >> >> -Andy >> >>> On Jul 27, 2016, at 9:57 AM

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

This was a CI infrastructure problem. Error copying a file. That’s why I directed to question to Mishal. The bot’s job coincided with locking the branch. -Andy > On Jul 27, 2016, at 10:23 AM, Andrew Trick via swift-dev > wrote: > > FYI: Swift CI just passed on this commit mi

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

This fails periodically: [TestIndirectEnumVariables.py FAILED] It’s definitely not my commit, which passed linux CI multiple times. -Andy > On Jul 27, 2016, at 11:13 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1783] > > Build URL: > https://ci.swift.o

Re: [swift-dev] End of source-breaking changes for Swift 3

> On Jul 27, 2016, at 1:21 PM, Jordan Rose via swift-dev > wrote: > >> SE-0107 - UnsafeRawPointer API >> Andy >> has been working on this. I still need to land one major source-breaking for UnsafePointer

[swift-dev] Anyone running build-toolchain on linux?

I need to push corelibs changes in today but I’m running into problems testing the full Swift toolchain on linux. build-toolchain stops after attempting to run swiftpm tests and hitting the failure shown below. Anyone else seeing issues running build-toolchain? As of: commit cb0b4588a6a8bf80dc

Re: [swift-dev] Anyone running build-toolchain on linux?

Thanks Ben. Daniel’s command works for me: build-script -R --llbuild --foundation --xctest -t But doesn’t build all the projects. -Andy > On Jul 28, 2016, at 9:39 AM, Ben Langmuir wrote: > > That error indicates some kind of filesystem issue in the module cache > directory - no permissions,

[swift-dev] Anyone fixing TestNSJSONSerialization?

Is anyone looking at this failure that’s blocking CI? https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6576/ TestFoundation/TestNSJSONSerialization.swift:301: error: TestNSJSONSerialization.test_deserialize_unicodeEscapeSequence : XCTAssertEqual failed: ("Optional("✨")") i

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

This turned out to be a spurious system failure. I unnecessarily reverted and reapplied my patch. -Andy > On Jul 29, 2016, at 12:37 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6946] > > Build URL: > https://ci.swift.org/job/oss-swift-incrementa

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

I must be building differently from the CI bot, because I’m hitting these failures trying to build playground support. I tried to fix the CI just by looking at the build log... /s/sptr/swift-xcode-playground-support/PlaygroundLogger/PlaygroundLogger_TestDriver/main.swift:19:1: error: use of unr

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

I fixed this playground logger build error, but it looks like this run didn’t pickup the fix yet. -Andy > On Jul 29, 2016, at 3:03 AM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-osx [#5577] > > Build URL:https://ci.swift.org/job/oss-swift-incremen

Re: [swift-dev] What exactly does it mean for a Swift pointer to be initialized?

> On Aug 5, 2016, at 12:43 PM, Jens Persson wrote: > > I'm trying to understand the new Swift 3 (4?) pointer API and Swift's memory > model. > > More specifically, I'd like to know more about what exactly it means for a > pointer to be initialized or not. > > For example, I suppose the follo

Re: [swift-dev] What exactly does it mean for a Swift pointer to be initialized?

> On Aug 5, 2016, at 10:42 PM, Dave Abrahams via swift-dev > wrote: > > > on Fri Aug 05 2016, Andrew Trick > wrote: > >>> On Aug 5, 2016, at 12:43 PM, Jens Persson wrote: >>> >>> I'm trying to understand the new Swift 3 (4?) pointer API and Swift's >>> memo

Re: [swift-dev] Rebinding UnsafePointer makes it mutable

> On Sep 19, 2016, at 1:24 AM, Martin R via swift-dev > wrote: > > I noticed that both UnsafePointer and UnsafeMutablePointer have the identical > method > >public func withMemoryRebound(to: T.Type, capacity count: Int, > _ body: (UnsafeMutablePointer) throws -> Result) rethrows -> Resul

Re: [swift-dev] Representing "address-only" values in SIL

> On Oct 3, 2016, at 12:10 PM, Alexis via swift-dev wrote: > > When I first started reading this proposal, my primary objection was going to > be that SSA doesn’t seem to really jive well with the idea of values becoming > (in)valid at some point in the future (due to moves). You can see this

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev > wrote: > >> I wonder whether it might make more sense for load [borrow] to be a >> different instruction. >> There's a couple reasons for that first. The first is that it's the only >> load which introduces >> a scope, which is

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

> On Oct 7, 2016, at 10:08 PM, Michael Gottesman wrote: > >> >> On Oct 7, 2016, at 9:25 PM, Andrew Trick > > wrote: >> >> >>> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> I wonder whether it might make

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

> On Oct 7, 2016, at 10:36 PM, Michael Gottesman wrote: > >> >> On Oct 7, 2016, at 10:26 PM, Andrew Trick > > wrote: >> >> >>> On Oct 7, 2016, at 10:08 PM, Michael Gottesman >> > wrote: >>> On Oct 7, 2016, at 9:25 PM, Andrew Tr

[swift-dev] [discussion notes] SIL address types and borrowing

On swift-dev, John already sent out a great writeup on SIL SSA: Representing "address-only" values in SIL. While talking to John I also picked up a lot of insight into how address types relate to SIL ownership and borrow checking. I finally organized the information into these notes. This is not a

Re: [swift-dev] [discussion notes] SIL address types and borrowing

; Karl > > P.S. going to pick up that unowned optional stuff soon, once I have time to > read the docs about SILGen There are SILGen docs somewhere? -Andy > >> On 8 Oct 2016, at 08:10, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >&g

Re: [swift-dev] [discussion notes] SIL address types and borrowing

> On Oct 8, 2016, at 12:39 AM, John McCall wrote: > >> %a = alloc_stack >> >> begin_exclusive %a >> apply foo(%a) // must be marked an initializer? >> end_exclusive %a >> >> begin_shared %a >> apply bar(%a) // immutable access >> end_shared %a >> >> dealloc_stack %a > > I think alloc_stack r

Re: [swift-dev] [discussion notes] SIL address types and borrowing

> On Oct 10, 2016, at 6:23 PM, Joe Groff wrote: > > >> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev >> wrote: >> ** World 1: SSA @inout >> >> Projecting an element produces a new SILValue. Does this SILValue have >> it's own

Re: [swift-dev] [discussion notes] SIL address types and borrowing

> On Oct 11, 2016, at 10:10 AM, Joe Groff wrote: > > >> On Oct 10, 2016, at 6:58 PM, Andrew Trick wrote: >> >> >>> On Oct 10, 2016, at 6:23 PM, Joe Groff wrote: >>> >>> >>>> On Oct 7, 2016, at 11:10 PM, An

Re: [swift-dev] [discussion notes] SIL address types and borrowing

gt;>> >>>> >>>>> On Oct 10, 2016, at 6:23 PM, Joe Groff wrote: >>>>> >>>>> >>>>>> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev >>>>>> wrote: >>>>>> ** World

Re: [swift-dev] [discussion notes] SIL address types and borrowing

cCall wrote: >>>>>>> >>>>>>>> On Oct 11, 2016, at 10:10 AM, Joe Groff via swift-dev >>>>>>>> wrote: >>>>>>>>> On Oct 10, 2016, at 6:58 PM, Andrew Trick wrote: >>>>>>>>> >>>>>&g

Re: [swift-dev] copy-on-write proposal

> On Oct 12, 2016, at 11:19 AM, Alexis via swift-dev > wrote: > > I’m having trouble figuring something out: is all of this contingent on all > of the relevant operations being completely inlined into a single function at > the SIL level? Could failing to inline a standard library function le

Re: [swift-dev] [semantic-arc][proposal] High Level ARC Memory Operations

This seems fine to me… at a high level! -Andy > On Oct 14, 2016, at 2:44 PM, Michael Gottesman via swift-dev > wrote: > > Attached below is a final version of the proposal. I am going to commit it to > the repo if there are no further questions/changes/etc. > >> https://gottesmm.github.io/pro

Re: [swift-dev] copy-on-write proposal

> On Oct 19, 2016, at 10:13 AM, Dave Abrahams via swift-dev > wrote: > > > on Tue Oct 18 2016, Erik Eckstein > wrote: > >>> On Oct 17, 2016, at 10:21 AM, Dave Abrahams wrote: >>> >>> >>> on Mon Oct 17 2016, Erik Eckstein wrote: >>> >> On Oct 16, 201

Re: [swift-dev] copy-on-write proposal

> On Oct 20, 2016, at 8:41 AM, Erik Eckstein wrote: > >> To clarify: I proposed an alternate approach in which the @sil_cow reference >> is only mutable during the Array’s @inout scope—to be automatically enforced >> by the compiler once @inout scopes are enforced. But the text in question is

Re: [swift-dev] Casting shadow protocols

> On Nov 7, 2016, at 12:15 PM, Alexis via swift-dev wrote: > > Does _unsafeReferenceCast at least verify that the types in question could > theoretically be cast into each other? That is, one is derived from the > other? If so, that would probably be an acceptable improvement. (the best we >

Re: [swift-dev] -Onone @inline(__always)?

Responding on swift-dev to what turned into an interesting discussion… > On Dec 1, 2016, at 11:19 AM, Joe Groff wrote: > >> >> On Dec 1, 2016, at 11:18 AM, Joe Groff wrote: >> >>> >>> On Dec 1, 2016, at 11:16 AM, Andrew Trick wrote: >>> >>> On Dec 1, 2016, at 10:34 AM, Jordan Rose w

Re: [swift-dev] -Onone @inline(__always)?

> On Dec 1, 2016, at 11:48 AM, Andrew Trick wrote: > > Responding on swift-dev to what turned into an interesting discussion… > >> On Dec 1, 2016, at 11:19 AM, Joe Groff > > wrote: >> >>> >>> On Dec 1, 2016, at 11:18 AM, Joe Groff >> > wrote:

Re: [swift-dev] -Onone @inline(__always)?

> On Dec 1, 2016, at 11:55 AM, Joe Groff wrote: > > >> On Dec 1, 2016, at 11:48 AM, Andrew Trick > > wrote: >> >> Responding on swift-dev to what turned into an interesting discussion… >> >>> On Dec 1, 2016, at 11:19 AM, Joe Groff >> > wrote:

Re: [swift-dev] Proposal: SILValue SSA Instructions

> On Dec 6, 2016, at 2:23 PM, John McCall via swift-dev > wrote: > >> On Dec 6, 2016, at 11:35 AM, Joe Groff > > wrote: >>> On Dec 6, 2016, at 11:29 AM, John McCall >> > wrote: >>> On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev >>>

Re: [swift-dev] Proposal: SILValue SSA Instructions

> On Dec 7, 2016, at 3:16 PM, Michael Gottesman wrote: > >> >> On Dec 7, 2016, at 2:52 PM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> >>> On Dec 6, 2016, at 2:23 PM, John McCall via swift-dev >> <mailto:

Re: [swift-dev] Proposal: SIL Ownership Model + Verifier

> On Dec 7, 2016, at 11:25 PM, John McCall via swift-dev > wrote: > >> >> On Dec 7, 2016, at 2:13 PM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> This is a proposal for a new SIL Ownership Model and verifier. An online >> HTML version of the document is avai

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

> On Jan 8, 2017, at 11:15 PM, Slava Pestov wrote: > > Assertion failed: (hasVal), function getValue, file > /Users/buildnode/jenkins/workspace/oss-swift-incremental-RA-osx/llvm/include/llvm/ADT/Optional.h, > line 122. > > This has been failing on and off all day… has anyone tried reproducing

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

> On Jan 9, 2017, at 12:00 AM, Andrew Trick via swift-dev > wrote: > >> On Jan 8, 2017, at 11:15 PM, Slava Pestov > <mailto:spes...@apple.com>> wrote: >> >> Assertion failed: (hasVal), function getValue, file >> /Users/buildnode/jenkins/worksp

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

This crasher is still failing to crash on Ubuntu 14.04 (crashes as expected on 16). I can’t imagine why the test would behave differently with the same target triple (x86_64-unknown-linux-gnu). Does anyone know how to REQUIRES: some-host? If not, I can lump this into deterministic-behavior. -And

[swift-dev] Proposal: Opaque SIL values

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 October—some info went out on swift-dev—but I realized there hasn’t been a formal proposal. So here it is. I w

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

I’m trying to revert this now: https://github.com/apple/swift/pull/7022 -Andy > On Jan 24, 2017, at 8:22 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_04 [#1474] > > Build URL: > https://ci.swift.org/job/oss-s

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

Mishal, I don’t see a failure here do you? What’s the magic string to search for in the console output? -Andy > On Jan 24, 2017, at 9:43 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#1549] > > Build URL: > https://ci.swift.

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

e workspace. Can you do that? -Andy > On Tue, Jan 24, 2017 at 9:46 PM, Andrew Trick via swift-dev > mailto:swift-dev@swift.org>> wrote: > Mishal, > > I don’t see a failure here do you? What’s the magic string to search for in > the console output? > > -Andy > &g

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

> On Jan 24, 2017, at 8:56 PM, Chris Lattner wrote: > > >> On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into ge

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

> On Jan 25, 2017, at 6:13 PM, Joe Groff wrote: > >> 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 f

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

> On Jan 25, 2017, at 4:22 PM, Karl Wagner wrote: > > >> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into generi

[swift-dev] Using git-clang-format in the Swift compiler code base.

Before I pull in a large PR that "accidentally" reformats a bunch of code, I want to get feedback on how Swift compiler devs plan to use `clang-format`. (BTW, here's the PR https://github.com/apple/swift/pull/6922). During the code review, I ran `git clang-format` as part of being a good citize

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 9:11 AM, Ben Langmuir wrote: >> >> ** Option 1: Add a simple configuration option to swift/.clang-format: >> >> 1a. BreakBeforeBinaryOperators: All >> >> 1b. BreakBeforeBinaryOperators: NonAssignment > >> >> I have absolutely no preference between 1a and 1b. It's purely

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

> On Jan 26, 2017, at 8:33 AM, John McCall wrote: > >> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into generic code optimiz

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 9:29 AM, Ben Langmuir wrote: > >> >> On Jan 26, 2017, at 9:14 AM, Andrew Trick > > wrote: >> >> >>> On Jan 26, 2017, at 9:11 AM, Ben Langmuir >> > wrote: ** Option 1: Add a simple configuration option to swi

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 10:25 AM, Jordan Rose wrote: > >> >> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >>> >>> On Jan 26, 2017, at 9:29 AM, Ben Langmuir >> <mailto:blangm...

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 10:34 AM, Andrew Trick via swift-dev > wrote: > > >> On Jan 26, 2017, at 10:25 AM, Jordan Rose > <mailto:jordan_r...@apple.com>> wrote: >> >>> >>> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev >> &l

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 11:38 AM, Graydon Hoare wrote: > > >> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev >> wrote: >> >> Before I pull in a large PR that "accidentally" reformats a bunch of code, I >> want to get feedback on

Re: [swift-dev] Using git-clang-format in the Swift compiler code base.

> On Jan 26, 2017, at 4:48 PM, Greg Parker wrote: > > >> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev >> wrote: >> >> Before I pull in a large PR that "accidentally" reformats a bunch of code, I >> want to get feedback on

[swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

I'm following up on a resilient dynamic dispatch discussion kicked off by Slava during a performance team meeting to summarize some key points on public [swift-dev]. It's easy to get sidetracked by the details of dynamic dispatch and various ways to generate code. I suggest approaching the problem

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

I don’t know what this could have to do with the changes in Runtime.swift. Speculatively reverting until it clears up: https://github.com/apple/swift/pull/7227 ArchetypeBuilder.cpp:2461: auto swift::ArchetypeBuilder::getGenericEnvironment(swift::GenericSignature *)::(anonymous class)::operator(

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 3, 2017, at 10:58 AM, John McCall wrote: > >> On Feb 2, 2017, at 9:57 PM, Andrew Trick via swift-dev >> wrote: >> --- >> #1. (thunk export) The simplest, most flexible way to expose dispatch >> across resilience boundaries is by exporting a sing

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev > wrote: > >>> #3b. (lazy resolution) Offset tables can be completely localized. >>> >>> method_index = immediate >>> { // common per-class method lookup >>> isa = load[obj] >&

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 3, 2017, at 1:27 PM, John McCall wrote: > >> On Feb 3, 2017, at 4:18 PM, Andrew Trick > <mailto:atr...@apple.com>> wrote: >>> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >&g

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 3, 2017, at 3:12 PM, John McCall wrote: > > I think we can generalize this discussion a bit by describing some > mostly-independent axes of variation: That's great (sorry I used up the arabic+letter naming convention earlier in the thread)... > I. A call site: > I1) inlines the loo

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 3, 2017, at 9:37 PM, John McCall wrote: > >>> IV. The function that performs the lookup: >>> IV1) is parameterized by an isa >>> IV2) is not parameterized by an isa >>> IV1 allows the same function to be used for super-dispatch but requires >>> extra work to be inlined at the call si

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 6, 2017, at 9:02 AM, Greg Parker wrote: > >> >> On Feb 4, 2017, at 2:35 AM, Andrew Trick via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> >>> On Feb 3, 2017, at 9:37 PM, John McCall >> <mailto:rjmcc...@apple.com&g

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 3, 2017, at 4:12 PM, Joe Groff wrote: > > Given that most open-coded resilient method lookup paths require an extra > load dependency to grab the method offset before loading the method address > itself, we might possibly consider indirecting the vtables for each class, so > that the

Re: [swift-dev] Resilient dynamic dispatch ABI. Notes and mini-proposal.

> On Feb 5, 2017, at 7:45 AM, Karl Wagner wrote: > > I have a question about current dispatching behaviour with protocols and > ‘Self’. > > protocol CustomEquatable { > func equal(to: Self) -> Bool > } > > open class Super : CustomEquatable { > func equal(to: Super) -> Bool { print("s

Re: [swift-dev] No return functions and program exit

> On Feb 6, 2017, at 12:19 PM, Michael Gottesman via swift-dev > wrote: > > >> On Feb 6, 2017, at 11:44 AM, Jordan Rose > > wrote: >> >> >>> On Feb 6, 2017, at 11:25, Joe Groff via swift-dev >> > wrote: >>> >>> On Feb 6, 2017,

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

Building CoreAudio on armv7k: (dependent_member_type assoc_type=Swift.(file).Strideable.Stride (base=generic_type_param_type depth=0 index=0 decl=Swift.(file).func decl.T)) deserialization produced an invalid type (rdar://problem/30382791) <>UNREACHABLE executed at /Users/buildnode/jenkins/wor

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

Something must have changed between the test and the merge. I’m just waiting on the PR revert’s smoke test. -Andy > On Apr 6, 2017, at 10:34 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#9249] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/9

Re: [swift-dev] [Swift CI] Build Failure: 1. OSS - Swift ASAN - OS X (master) #398

I probably messed up an instruction iterator… fixing. -Andy > On Apr 10, 2017, at 1:13 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-ASAN-RA-osx [#398] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-ASAN-RA-osx/398/ >

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

> runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED This is unrelated to my commit and recovered on the next build. Is it spurious? Can CI be taught to recognize known spurious asserts? -Andy > On Apr 14, 2017, at 7:51 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-

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

> runtime/SwiftRuntimeTests/MetadataTest.getExistentialMetadata’ FAILED This is the same failure again, which seems sensitive to me checking anything at all in. -Andy > On Apr 14, 2017, at 10:10 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [

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

Backtrace: #1 0x0398c9f6 SignalHandler(int) (/home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-16_10/buildbot_incremental/swift-linux-x86_64/bin/swift+0x398c9f6) #2 0x7f5e37c6f670 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11670) #3 0x0392f35e

Re: [swift-dev] Renaming SILSuccessor -> SILCFGEdge

> On Apr 26, 2017, at 1:24 PM, Michael Gottesman via swift-dev > wrote: > > Hey everyone. > > I am currently doing some small fixes to SILSuccessor (adding some comments > and fixing some issues exposed by LLVM upstream). As I read the code it > became pretty apparent that the name is a misn

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

TestFoundation/TestFoundation: undefined symbol: _T0s10DictionaryV4keyss17LazyMapCollectionVyAByxq_GxGfg -Andy > On Apr 28, 2017, at 9:51 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#3350] > > Build URL: > https://ci.swift.

Re: [swift-dev] Dependencies on Benchmark_O(& co.) --verbose format

Hi Pavol, The compare_perf_tests.py script parses that output. I don’t actually use the driver. I might start using the driver once it has a —rerun option, but the compare script should still work directly on the benchmark output. -Andy > On May 15, 2017, at 2:42 AM, Pavol Vaskovic via swift-d

  1   2   >