[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

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

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

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

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

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

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

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

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 > <swift-dev@swift.org> wrote: > > FYI: Sw

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

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

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 >

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:

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

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 <swift-dev@swift.org> > wrote: > > Slava, > > This started failing after your commit: > http

[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

[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("✨")")

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:

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

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

[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

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:

[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

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

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

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

> On Feb 3, 2017, at 10:58 AM, John McCall <rjmcc...@apple.com> wrote: > >> On Feb 2, 2017, at 9:57 PM, Andrew Trick via swift-dev <swift-dev@swift.org> >> wrote: >> --- >> #1. (thunk export) The simplest, most flexible way to expose dispatch >&

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

> On Feb 3, 2017, at 11:55 AM, Andrew Trick via swift-dev <swift-dev@swift.org> > wrote: > >>> #3b. (lazy resolution) Offset tables can be completely localized. >>> >>> method_index = immediate >>> { // common per-class me

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

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

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

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

> On Feb 6, 2017, at 9:02 AM, Greg Parker <gpar...@apple.com> wrote: > >> >> On Feb 4, 2017, at 2:35 AM, Andrew Trick via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> >>> On Feb 3, 2017,

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:

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

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

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

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

ean the workspace. Can you do that? -Andy > On Tue, Jan 24, 2017 at 9:46 PM, Andrew Trick via swift-dev > <swift-dev@swift.org <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 cons

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

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

> On Jan 24, 2017, at 8:56 PM, Chris Lattner <sa...@nondot.org> wrote: > > >> On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev >> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >> >> I’m sending out a proposal for fundament

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:

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

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

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

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 > <swift-dev@swift.org> wrote: > > >> On Jan 26, 2017, at 10:25 AM, Jordan Rose <jordan_r...@apple.com >> <mailto:jordan_r...@apple.com>> wrote: >> >>> >>> On Jan 2

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

[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

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

> On Jan 25, 2017, at 4:22 PM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> I’m sending out a proposal for fundament

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

> On Jan 26, 2017, at 4:48 PM, Greg Parker <gpar...@apple.com> wrote: > > >> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev >> <swift-dev@swift.org> wrote: >> >> Before I pull in a large PR that "accidentally" reformats a

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

> On Jan 26, 2017, at 11:38 AM, Graydon Hoare <gho...@apple.com> wrote: > > >> On Jan 26, 2017, at 2:07 AM, Andrew Trick via swift-dev >> <swift-dev@swift.org> wrote: >> >> Before I pull in a large PR that "accidentally" reformats a

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

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

[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

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

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

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

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)

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

> On Oct 10, 2016, at 6:23 PM, Joe Groff <jgr...@apple.com> wrote: > > >> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev >> <swift-dev@swift.org> wrote: >> ** World 1: SSA @inout >> >> Projecting an element produces a new SILV

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

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

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

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

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

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

> On Oct 11, 2016, at 10:10 AM, Joe Groff <jgr...@apple.com> wrote: > > >> On Oct 10, 2016, at 6:58 PM, Andrew Trick <atr...@apple.com> wrote: >> >> >>> On Oct 10, 2016, at 6:23 PM, Joe Groff <jgr...@apple.com> wrote: >>> &g

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

rote: >>>> On Oct 10, 2016, at 6:58 PM, Andrew Trick <atr...@apple.com> wrote: >>>> >>>> >>>>> On Oct 10, 2016, at 6:23 PM, Joe Groff <jgr...@apple.com> wrote: >>>>> >>>>> >>>>>> On Oct

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

gt;> <swift-dev@swift.org> wrote: >>>>>>>>> On Oct 10, 2016, at 6:58 PM, Andrew Trick <atr...@apple.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Oct 10, 2016, at 6:23

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:

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 >> > wrote: >> >> This is a proposal for a new SIL Ownership Model and verifier. An

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

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

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.

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

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

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]

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] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - Ubuntu 16.10 (master) #4985

ple/swift-corelibs-foundation/pull/1156> -Andy > On Aug 2, 2017, at 3:41 PM, Andrew Trick via swift-dev <swift-dev@swift.org> > wrote: > > Ian, I’m not sure why PR testing didn’t report this failure (is there a PR?). > Would you be able to revert to unblock PR testing un

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

Ian, I’m not sure why PR testing didn’t report this failure (is there a PR?). Would you be able to revert to unblock PR testing until this is fixed? Test Case 'TestNotificationCenter.test_postNotification' started at 2017-08-02 22:33:02.555

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

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

> On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev > wrote: > > The Swift runtime currently maintains globally unique pointer identities for > type metadata and protocol conformances. This makes checking type equivalence > a trivial pointer equality comparison, but

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

@apple.com >>> <mailto:atr...@apple.com>> wrote: >>>> On Jul 28, 2017, at 3:15 PM, John McCall <rjmcc...@apple.com >>>> <mailto:rjmcc...@apple.com>> wrote: >>>>> On Jul 28, 2017, at 6:02 PM, Andrew Trick via swift-dev >>&g

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

Jordan, Dave, Are you reverting/fixing now? -Andy > On Aug 1, 2017, at 9:41 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#11359] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/11359/ >

Re: [swift-dev] [Swift CI] Build Failure: OSS - Swift Package - OS X (master) #3906

Jordan and Alex are racing to fix it: https://github.com/apple/swift/pull/11288 Commit Summary [swift-api-digester] Update for 'deinit' as a special name. > On Aug 1, 2017, at 10:41 AM, Mishal Shah wrote: > >

Re: [swift-dev] Enums with Many Cases/Covered Switches

> On Aug 1, 2017, at 10:49 AM, Michael Gottesman wrote: > > I was reading https://github.com/apple/swift/pull/11098 and it brought my > mind back to a strawman discussion that Roman and I had some time ago. > Namely, in some cases, we want the functionality of a covered

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

> On Jul 28, 2017, at 3:15 PM, John McCall <rjmcc...@apple.com> wrote: > >> >> On Jul 28, 2017, at 6:02 PM, Andrew Trick via swift-dev >> <swift-dev@swift.org> wrote: >> >> >>> On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev <

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

I don’t know what this is about. Could you clean the workspace to see if it clears up? Test Case 'TestURLSession.test_httpRedirection' started at 2017-08-19 04:43:11.694 /home/buildnode/jenkins/workspace/oss-swift-incremental-RA-linux-ubuntu-14_04/swift/utils/build-script-impl: line 261: 30177

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

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

> On May 15, 2017, at 11:20 PM, Pavol Vaskovic wrote: > > On Mon, May 15, 2017 at 7:48 PM, Andrew Trick > wrote: > The compare_perf_tests.py script parses that output. > > I am aware of that one. But my question is specifically about

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 1:45 PM, Pavol Vaskovic wrote: > > On Tue, May 16, 2017 at 9:10 PM, Dave Abrahams via swift-dev > > wrote: > > on Thu May 11 2017, Pavol Vaskovic wrote: > > I have run Benchmark_O with --num-iters=100 on my

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 2:55 PM, Michael Gottesman wrote: > >> Current approach to detecting performance changes is fragile for tests that >> have very low absolute runtime, as they are easily over the 5% >> improvement/regression threshold when the test machine gets a

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 4:45 PM, Pavol Vaskovic wrote: > > I have sketched an algorithm for getting more consistent test results, so far > its in Numbers. I have ran the whole test suite for 100 samples and observed > the varying distribution of test results. The first result is

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 5:29 PM, Michael Gottesman wrote: > >> I don't know what that is. > > Check it out: https://en.wikipedia.org/wiki/Mann–Whitney_U_test > . It is a > non-parametric test that two sets of

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 4:45 PM, Pavol Vaskovic wrote: > > We really have two problems: > 1. spurious results > 2. the turnaround time for the entire benchmark suite > > > I don't think we can get more consistent test results just from re-running > tests that were detected as

Re: [swift-dev] Measuring MEAN Performance (was: Questions about Swift-CI)

> On Jun 12, 2017, at 5:55 PM, Pavol Vaskovic wrote: > > > > On Tue, Jun 13, 2017 at 2:31 AM, Michael Gottesman > wrote: >> I don't think we can get more consistent test results just from re-running >> tests that were

Re: [swift-dev] Questions about Swift-CI

> On May 11, 2017, at 1:33 PM, Pavol Vaskovic via swift-dev > wrote: > > Douglas Gregor suggested in SR-4814 (that was merged as dupe into SR-4669) > that I get in contact with you because I’m working on issue SR-4669 Add a > Benchmark_Driver --rerun N option

Re: [swift-dev] PR-9995: enable exclusivity runtime checks.

Runtime checks only take effect at -Onone. Even if you explicitly ask for checks via -enforce-exclusivity=checked, they will be stripped (with a warning from the driver). Support for dynamic checking at -O is something that will be considered post Swift 4. -Andy > On Jun 1, 2017, at 4:47 PM,

[swift-dev] PR-9995: enable exclusivity runtime checks.

Hi swift-dev, PR-9995 enables exclusivity runtime checks: https://github.com/apple/swift/pull/9995 These checks catch violations of exclusivity that can't be discovered statically [0], printing the message: "Simultaneous accesses to 0x*, but modification requires exclusive access." The error

Re: [swift-dev] statically initialized arrays

> On Jun 14, 2017, at 12:03 PM, Jordan Rose via swift-dev > wrote: > >> ad 3) IRGen support >> >> Generating statically initialized globals is already done today for structs >> and tuples. >> What’s needed is the handling of objects. >> In addition to creating the global

Re: [swift-dev] statically initialized arrays

> On Jun 15, 2017, at 4:26 PM, Andrew Trick wrote: > > >> On Jun 14, 2017, at 12:03 PM, Jordan Rose via swift-dev > > wrote: >> >>> ad 3) IRGen support >>> >>> Generating statically initialized globals is already done today

  1   2   >