Re: [swift-dev] RFC: Adding Optional variants of == for collections to the std lib

> On Dec 5, 2015, at 12:39 PM, Martin Kühl via swift-dev > wrote: > On 5 December 2015 at 16:38, Paul Young wrote: >> >> I’d like to get a sense from contributors to the standard library if they >> feel that the functionality in >> https://github.com/paulyoung/OptionalEquatableCollection has

Re: [swift-dev] [RFC] SIL syntax for debug information Part 1: Variables

> On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev > wrote: >> On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-dev >> wrote: >> >> In order to write textual SIL -> SIL testcases that exercise the handling of >> debug information by SIL passes, we need to make a couple of additions to

Re: [swift-dev] Thread safety of weak properties

> On Dec 10, 2015, at 6:50 PM, Mike Ash via swift-dev > wrote: > Hello, world! > > First, congratulations on the whole open source thing. I'm really pleased to > see how the team set it up and how well it's going. Blew away my expectations. > > Anyway, on to the thing. > > I was looking throu

Re: [swift-dev] Thread safety of weak properties

> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote: > #3 sounds like a great approach to me. I agree with Kevin that if we keep > the object husk approach that any use of a weak pointer that returns nil > should drop any reference to a husk. Spin locks are, unfortunately, illegal on iOS, which

Re: [swift-dev] Pointers vs. References?

> On Dec 12, 2015, at 4:20 PM, Michael Gottesman via swift-dev > wrote: > In general, we have not been particularly disciplined in this regard. I would > suggest following what is being done locally in the file you are modifying, > i.e. FuncDecl */TypeChecker & as per the LLVM style guide. The

Re: [swift-dev] Pointers vs. References?

> On Dec 14, 2015, at 11:43 AM, Jacob Bandes-Storch wrote: > I was thinking it might help some of the null-dereference issues if more > things were to be passed as references. Is there a particular reason to use > pointers instead? It seems there are several places which accept pointers and > a

Re: [swift-dev] [RFC] SIL syntax for debug information Part 1: Variables

> On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote: >> On Dec 10, 2015, at 10:19 AM, John McCall wrote: >> >>> On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev >>> wrote: On Dec 9, 2015, at 4:15 PM, Adrian Prantl via swift-dev wrote: In order to write textual SIL ->

Re: [swift-dev] [RFC] SIL syntax for debug information Part 1: Variables

> On Dec 15, 2015, at 3:01 PM, Adrian Prantl wrote: >> On Dec 15, 2015, at 2:35 PM, John McCall wrote: >> >>> On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote: On Dec 10, 2015, at 10:19 AM, John McCall wrote: > On Dec 10, 2015, at 8:31 AM, Joe Groff via swift-dev > wrote:

Re: [swift-dev] Thread safety of weak properties

> On Dec 15, 2015, at 6:01 PM, Greg Parker via swift-dev > wrote: >> On Dec 15, 2015, at 5:32 PM, Kevin Ballard wrote: >> >>> On Tue, Dec 15, 2015, at 01:38 PM, Greg Parker via swift-dev wrote: >>> >>> Another solution is to use a handoff lock algorithm. This is what libobjc >>> does now. The

Re: [swift-dev] Thread safety of weak properties

> On Dec 15, 2015, at 6:27 PM, Kevin Ballard wrote: > On Tue, Dec 15, 2015, at 06:12 PM, John McCall wrote: >> So, just to complete the loop here: absent Darwin granting public and >> backwards-compatible access to an internal API, we need to write this in a >> way that falls back on using a hea

Re: [swift-dev] `withUnsafePointer` mutates `self`

> On Dec 16, 2015, at 12:12 AM, Dave Abrahams via swift-dev > wrote: >> On Dec 15, 2015, at 11:51 PM, Kevin Ballard wrote: >> On Tue, Dec 15, 2015, at 11:25 PM, Dave Abrahams wrote: >>> On Dec 15, 2015, at 6:46 PM, Kevin Ballard wrote: On Tue, Dec 15, 2015, at 06:39 PM, Dave Ab

Re: [swift-dev] Breaking change in lexing operators next to comments

> On Dec 17, 2015, at 6:32 AM, Jesse Rusak via swift-dev > wrote: > Any other comments about this? Can someone from the core team make a call on > this, or should we ask for comments on swift-evolution? It has to go through swift-evolution anyway, but yes, I completely agree that comments shou

Re: [swift-dev] inout and aliasing in the optimizer

> On Dec 17, 2015, at 2:48 PM, Joe Groff via swift-dev > wrote: >> On Dec 17, 2015, at 2:34 PM, Erik Eckstein via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> Hi, >> >> I'm currently working on improving alias analysis in the optimizer and I run >> into following problem: >> >> If

Re: [swift-dev] Value-result ABI for small trivial inouts

> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev > wrote: > We currently always pass inout parameters indirectly, but it seems to me that > for inout parameters that are of small trivial types like Int or CGSize, a > value-result calling convention might always be preferable, and we might

Re: [swift-dev] Value-result ABI for small trivial inouts

> On Dec 17, 2015, at 11:09 PM, Slava Pestov via swift-dev > wrote: >> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev >> wrote: >> >> We currently always pass inout parameters indirectly, but it seems to me >> that for inout parameters that are of small trivial types like Int or >> CGS

Re: [swift-dev] Value-result ABI for small trivial inouts

> On Dec 18, 2015, at 10:29 AM, Joe Groff wrote: >> On Dec 17, 2015, at 3:43 PM, John McCall wrote: >> >>> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev >>> wrote: >>> We currently always pass inout parameters indirectly, but it seems to me >>> that for inout parameters that are of sma

Re: [swift-dev] SIL: "unowned" the calling convention and "unowned" the variable ownership convention

> On Jan 4, 2016, at 11:07 AM, Jordan Rose via swift-dev > wrote: > Hi, Michael. The calling convention is equivalent to the 'unowned(unsafe)' > variant of 'unowned', so I don't think it's entirely unrelated. > > I don't like "Immediate" because I don't know what it means. Admittedly I > don't

Re: [swift-dev] [Discussion] New refcount representation

> On Mar 15, 2016, at 11:59 PM, Greg Parker via swift-dev > wrote: > I am considering a new representation for Swift refcounts and other > per-object data. This is an outline of the scheme. Comments and suggestions > welcome. There are a lot of really good ideas. I would like to see some quas

Re: [swift-dev] Returning more than two scalars from C code

> On Mar 22, 2016, at 12:25 PM, Joe Groff wrote: >> On Mar 22, 2016, at 12:06 PM, Bryan Chan > > wrote: >> >> jgr...@apple.com wrote on 2016-03-22 02:37:47 PM: >> >> > The runtime functions are hacked in various unsavory ways to give >> >

Re: [swift-dev] Swift kernel hacking, compiler options and target triples

> On Mar 28, 2016, at 11:16 AM, Simon Evans via swift-dev > wrote: > Hi > > I’ve been experimenting with kernel programming in Swift and this required > disabling the use of the red zone. Currently Im compiling to ELF on Linux and > linking in my own minimal libc/libcpp with libswiftCore.a so it

Re: [swift-dev] Returning more than two scalars from C code

> On Mar 30, 2016, at 12:09 PM, Bryan Chan wrote: > > Thanks for your responses so far. It took me a while to fully appreciate > what all this means. > > I have read through John's mail thread on llvm-dev about adding the swiftcc > convention to LLVM/Clang. I don't think that discussion mentione

Re: [swift-dev] isUniquelyReferenced issues

> On Apr 1, 2016, at 4:10 PM, Andrew Trick via swift-dev > wrote: >> 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 >>> -Ono

Re: [swift-dev] CoerceAndExpand switch warnings after latest clang/llvm stable merge

> On Apr 4, 2016, at 3:02 PM, David Farler via swift-dev > wrote: > Just a heads up - the latest stable merge exposed a couple of switch warnings: > > swift/lib/IRGen/GenFunc.cpp:1338:13: warning: enumeration value > 'CoerceAndExpand' not handled in switch [-Wswitch] >switch (AI.getKind())

Re: [swift-dev] swift (ABI) and Windows

> On Apr 6, 2016, at 11:18 AM, Jordan Rose via swift-dev > wrote: > > Hey, Saleem. How do you expect this to differ from normal symbol visibility? > It seems to me that in a shared library, any public symbol is either exported > or imported, depending on whether it has a definition, and any no

[swift-dev] A type-checking performance case study

The standard library team asked the compiler team to take a look at the performance of the type-checker. Their observation was that several in-progress additions to the standard library were causing a disproportionate increase in the time it required to compile a simple-seeming expression, and

Re: [swift-dev] [swift] master, stable-swift-3.0-merge-branch: [SourceKit] Use DARWIN_TOOLCHAIN_VERSION if provided, as the version to use for the XPC service name. (f242326)

> On Apr 7, 2016, at 9:34 PM, Argyrios Kyrtzidis via swift-commits > wrote: > > Repository : github.com/apple/swift > On branches: master,stable-swift-3.0-merge-branch Hey, to whomever it may concern: commit notification e-mails started going out like this this morning, with "stable-swift-3.0-

Re: [swift-dev] A type-checking performance case study

> On Apr 11, 2016, at 8:35 AM, Joe Groff wrote: >> On Apr 8, 2016, at 11:47 AM, John McCall via swift-dev >> wrote: >> >> One very drastic solution to this problem would be to eliminate non-labelled >> overloads. (A perhaps more-reasonable way to describe

Re: [swift-dev] Lazy var and deinit

> On Apr 21, 2016, at 2:29 AM, Alexandr.moq via swift-dev > wrote: > Should SWIFT initialize a variable in deinit method if it has not been > initialized? > > For example: > ```swift > class A { > lazy var b = B() > deinit { > b.clean() > } > } > var a = A() >

Re: [swift-dev] test-repl-glibc failure

> On Apr 22, 2016, at 11:09 AM, William Dillon via swift-dev > wrote: > For me an objection to xfailing this is that it really isn't an expected > fail. Linux is actually broken. And it's therefore expected to fail until we fix it. Ideally, whoever added this understands that it's their respo

Re: [swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

> On Apr 22, 2016, at 3:33 PM, Douglas Gregor via swift-dev > wrote: > Hi all, > > A common complaint with protocol conformance checking is that it’s easy to > make a little mistake when trying to implement a protocol requirement that > has a default implementation. Here is a silly example: >

Re: [swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

> On Apr 25, 2016, at 9:57 AM, Douglas Gregor wrote: >> On Apr 22, 2016, at 6:08 PM, John McCall > > wrote: >> >>> On Apr 22, 2016, at 3:33 PM, Douglas Gregor via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> Hi all, >>> >>> A common complaint with protocol co

Re: [swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

> On Apr 25, 2016, at 10:12 AM, Douglas Gregor wrote: >> On Apr 25, 2016, at 10:09 AM, John McCall > > wrote: >> >>> On Apr 25, 2016, at 9:57 AM, Douglas Gregor >> > wrote: On Apr 22, 2016, at 6:08 PM, John McCall >>>

Re: [swift-dev] [Compiler] Help IR gen in targetting MSVC

> On Apr 25, 2016, at 7:54 PM, Sangjin Han via swift-dev > wrote: > Hi all, > > I found a bug in my port for MSVC and Cygwin. > > The C function swift_stdlib_readLine_stdin() is mapped to 'Int' type in > Swift, but it generates i32 in LLVM if I specify the target as MSVC. If I > give the targ

Re: [swift-dev] swift (ABI) and Windows

> On Apr 26, 2016, at 8:43 AM, Saleem Abdulrasool wrote: > On Tue, Apr 12, 2016 at 9:32 AM, Saleem Abdulrasool > wrote: > On Monday, April 11, 2016, Joe Groff > wrote: > > > On Apr 11, 2016, at 3:19 PM, Saleem Abdulrasool via swift-dev > >

Re: [swift-dev] [Compiler] Help IR gen in targetting MSVC

> On Apr 26, 2016, at 1:03 PM, Sangjin Han wrote: > The problem can be solved by modifying that code. Thanks you. I thought that > code will affect only to the CLong type not Int. It changes what 'long' gets imported as. If there's a Windows API defined using 'long' (rather than some more mean

Re: [swift-dev] [swift-evolution] [Compiler] Help IR gen in targetting MSVC

> On Apr 26, 2016, at 1:39 PM, Joe Groff wrote: >> On Apr 26, 2016, at 1:24 PM, John McCall via swift-evolution >> wrote: >> >>> On Apr 26, 2016, at 1:03 PM, Sangjin Han wrote: >>> The problem can be solved by modifying that code. Thanks you. I thought >>> that code will affect only to the CL

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

> On May 11, 2016, at 3:40 PM, Bob Wilson wrote: > John, this is yours, right? Yeah, I'll take a look. John. > >> On May 11, 2016, at 3:38 PM, no-re...@swift.org >> wrote: >> >> [FAILURE] oss-swift-incremental-RA-osx [#3999] >> >> Build URL: https://ci.swift.or

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

> On May 12, 2016, at 10:45 AM, Jordan Rose via swift-dev > wrote: >> On May 12, 2016, at 10:44, Joe Groff > > wrote: >> >> >>> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev >> > wrote: >>> >>> >>> - I’m uncomfortable with using th

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

> 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 wrote: > On May 12, 2016, at 9:27 AM, Jordan Rose via swift-d

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

> On May 12, 2016, at 7:47 PM, Jordan Rose via swift-dev > wrote: >> On May 12, 2016, at 18:56, Andrew Trick > > wrote: >> >>> - What was the thought behind putting UnsafeBytePointer in PointerTypeKind? >>> OpaquePointer isn’t there, and I’m concerned about places that

Re: [swift-dev] Automator service: "View Public Swift Commit"

> On May 18, 2016, at 11:13 AM, Jordan Rose via swift-dev > wrote: > > Hi, fellow Mac users. On GitHub, commit hashes are autolinked (within > repositories, anyway), but that doesn't apply to mail clients, or, um, > external bug tracking clients *cough*Radar*cough*. I've found myself wanting

Re: [swift-dev] Relative Pointers and Windows ARM

> On May 18, 2016, at 1:51 PM, Saleem Abdulrasool wrote: > Hi, > > It seems that there are assumptions about the ability to create relative > address across sections which doesn't seem possible on Windows ARM. > > Consider the following swift code: > > final class _ContiguousArrayStorage { } >

Re: [swift-dev] Relative Pointers and Windows ARM

> On May 19, 2016, at 5:39 PM, Saleem Abdulrasool wrote: > On Thu, May 19, 2016 at 9:07 AM, John McCall > wrote: > > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool > > wrote: > > Hi, > > > > It seems that there are assumptions about the a

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

> On May 20, 2016, at 7:56 AM, Chris Lattner wrote: > 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: >>>>> >

Re: [swift-dev] Relative Pointers and Windows ARM

> On May 21, 2016, at 1:01 PM, Saleem Abdulrasool via swift-dev > wrote: > On Thu, May 19, 2016 at 12:29 PM, Joe Groff > wrote: > > > On May 19, 2016, at 12:22 PM, Tom Birch > > wrote: > > > > Would it be acceptable to make relative pointers op

Re: [swift-dev] AST – Understanding @lvalue

> On May 24, 2016, at 9:48 AM, Tim Bodeit via swift-dev > wrote: > I couldn’t find any documentation about lvalues in Swift. Can anybody give me > a short explanation of what exactly an lvalue is? > > In C++ all variables, including those marked with the const modifier seem to > be lvalues. It

Re: [swift-dev] COFF indirect addressing and protocol conformance tables ABI issues

> On Jul 3, 2016, at 2:40 PM, Saleem Abdulrasool wrote: > Hello again, > > I come bearing more problems :-). > > I seem to have found another point in the ABI which prevents an easy port of > swift to Windows without an emulation layer underneath. This time it deals > with the protocol confor

Re: [swift-dev] COFF indirect addressing and protocol conformance tables ABI issues

> On Jul 5, 2016, at 5:56 PM, Saleem Abdulrasool wrote: > On Tue, Jul 5, 2016 at 10:30 AM, John McCall > wrote: > > On Jul 3, 2016, at 2:40 PM, Saleem Abdulrasool > > wrote: > > Hello again, > > > > I come bearing more problems :-). > > >

Re: [swift-dev] COFF indirect addressing and protocol conformance tables ABI issues

> On Jul 6, 2016, at 7:33 AM, Saleem Abdulrasool wrote: > On Tue, Jul 5, 2016 at 6:28 PM, John McCall > wrote: >> On Jul 5, 2016, at 5:56 PM, Saleem Abdulrasool > > wrote: >> On Tue, Jul 5, 2016 at 10:30 AM, John McCall >

[swift-dev] id-as-Any and ObjC generic parameters

Suppose we are calling a function that is generic over T, where T: AnyObject. This comes up when e.g. calling an initializer for an ObjC generic class. Today we allow conversions from [String] to [NSString], String to NSString, and [String] to [T], but we do not allow a conversion from String t

Re: [swift-dev] id-as-Any and ObjC generic parameters

> On Jul 7, 2016, at 8:17 PM, Joe Groff wrote: >> On Jul 7, 2016, at 5:26 PM, John McCall wrote: >> >> Suppose we are calling a function that is generic over T, where T: >> AnyObject. This comes up when e.g. calling an initializer for an ObjC >> generic class. >> >> Today we allow conversion

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

> On Jul 26, 2016, at 2:29 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04-long-test [#599] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04-long-test/599/ > >

Re: [swift-dev] [SIL] Deconstructing partial_apply

> On Sep 6, 2016, at 3:36 PM, Joe Groff via swift-dev > wrote: > Last week, I put some effort into trying to reduce the power of SIL's > infamous partial_apply instruction. The instruction was intended to make > representation and optimization of closures easy by avoiding concretization > of t

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

> On Sep 9, 2016, at 10:46 AM, no-re...@swift.org wrote: > [FAILURE] oss-swift-incremental-RA-osx [#6213] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/6213/ > > Project: oss-swift-incremental-RA-osx > Da

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

> On Sep 9, 2016, at 10:51 AM, John McCall via swift-dev > wrote: > >> On Sep 9, 2016, at 10:46 AM, no-re...@swift.org <mailto:no-re...@swift.org> >> wrote: >> [FAILURE] oss-swift-incremental-RA-osx [#6213] >> >> Build URL: https://ci.sw

Re: [swift-dev] why are we accepting switch statements with duplicate conditions?

> On Sep 14, 2016, at 10:25 AM, Ted Kremenek via swift-dev > wrote: > > Hi everyone, > > Joe Shajrawi nominated an optimizer fix for Swift 3.0.1 where the optimizer > was crashing due to duplicate conditions in aswitchstatement: > > https://bugs.swift.org/browse/SR-2512

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

Andy Trick and I had this conversation Thursday, and I thought I'd capture it here. The Problem It's a longstanding complaint that SIL uses drastically different code patterns for the same sequence of operations based on whether the types of the values involved are loadable or "address-only".

Re: [swift-dev] Does it make sense to fold FreeBSD specific patches to Swift into the upstream codebase?

> On Oct 2, 2016, at 10:59 AM, Steve Wills via swift-dev > wrote: > On 10/02/2016 13:38, Brendan Sechter wrote: >> Currently the Swift source code is being patched so that it will build >> on FreeBSD. Does it make sense to just fold (most of?) these changes >> into the upstream Swift codebase? >

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

> On Oct 3, 2016, at 9:22 AM, Joe Groff wrote: > > I feel like moving in this direction is the right thing to do. Some random > comments below: > >> On Oct 1, 2016, at 1:32 AM, John McCall via swift-dev >> wrote: >> >> Andy Trick and I had this c

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

ly valid*. But that's true of the SSA dominance restriction as well. John. > > -Andy > >> >>> On Oct 1, 2016, at 4:32 AM, John McCall via swift-dev >> <mailto:swift-dev@swift.org>> wrote: >>> >>> Andy Trick and I had this convers

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

> On Sep 30, 2016, at 11:54 PM, Michael Gottesman via swift-dev > wrote: > > The document attached below contains the first "Semantic ARC" mini proposal: > the High Level ARC Memory Operations Proposal. > > An html rendered version of this markdown document is available at the > following UR

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

> On Oct 5, 2016, at 4:48 PM, Michael Gottesman wrote: >> On Oct 5, 2016, at 4:40 PM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >>> >>> On Oct 4, 2016, at 1:04 PM, John McCall >> > wrote: >>> On Sep 30, 2016, at 11:54 PM, Mi

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

> On Oct 7, 2016, at 2:38 PM, Michael Gottesman wrote: > > Attached below is an updated version of the proposal. Again a rendered > version is located at: > > https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html >

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

> On Oct 7, 2016, at 6:04 PM, Michael Gottesman wrote: >> On Oct 7, 2016, at 5:09 PM, John McCall > > wrote: >>> On Oct 7, 2016, at 2:38 PM, Michael Gottesman >> > wrote: >>> >>> Attached below is an updated version of the proposal. Again a

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

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

> On Oct 7, 2016, at 10:46 PM, Andrew Trick wrote: >> 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] swift (ABI) and Windows

> On Oct 7, 2016, at 4:08 PM, Paul Menage wrote: > On Tue, Apr 26, 2016 at 8:49 AM, John McCall via swift-dev > wrote: >> >> I think it's reasonable to assume that @_silgen_name is not being used for >> objects that are external to the declaring module. That is

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

> On Oct 7, 2016, at 11:10 PM, Andrew Trick via swift-dev > wrote: > > 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 b

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

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

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

> On Oct 11, 2016, at 11:22 AM, Joe Groff wrote: >> On Oct 11, 2016, at 11:19 AM, Andrew Trick wrote: >> >> >>> On Oct 11, 2016, at 11:02 AM, Joe Groff wrote: >>> >>> On Oct 11, 2016, at 10:50 AM, John McCall wrote: > On Oct 11, 2016, at 10:10 AM, Joe Groff via swift-dev >>>

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

> On Oct 11, 2016, at 11:49 AM, Joe Groff wrote: >> On Oct 11, 2016, at 11:44 AM, John McCall wrote: >> >>> On Oct 11, 2016, at 11:22 AM, Joe Groff wrote: On Oct 11, 2016, at 11:19 AM, Andrew Trick wrote: > On Oct 11, 2016, at 11:02 AM, Joe Groff wrote: > >

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

> On Oct 11, 2016, at 4:48 PM, Andrew Trick wrote: >> On Oct 11, 2016, at 2:14 PM, John McCall wrote: >> >>> On Oct 11, 2016, at 11:49 AM, Joe Groff wrote: On Oct 11, 2016, at 11:44 AM, John McCall wrote: > On Oct 11, 2016, at 11:22 AM, Joe Groff wrote: >> On Oct 11, 2016,

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev > wrote: > I just tracked down a bug due to C++ code in the Swift runtime code trying to > interface with standard library code written in Swift, but getting the ABI > slightly wrong and leading to some nasty hard-to-reproduce heisenbugs. W

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> On Oct 12, 2016, at 3:46 PM, Greg Parker wrote: >> On Oct 12, 2016, at 11:11 AM, John McCall via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >>> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev >> <mailto:swift-dev@swift.org>> wrot

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Oct 13, 2016, at 9:04 AM, Joe Groff via swift-dev > wrote: > > >> On Mar 1, 2016, at 1:33 PM, Joe Groff via swift-dev > > wrote: >> >> In swift_retain/release, we have an early-exit check to pass through a nil >> pointer. Since we're already burning branch, I

Re: [swift-dev] Validating ABI consistency between runtime C++ and standard library Swift code

> On Oct 13, 2016, at 9:30 AM, Michael Gottesman wrote: >> On Oct 12, 2016, at 4:36 PM, John McCall via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >>> On Oct 12, 2016, at 3:46 PM, Greg Parker >> <mailto:gpar...@apple.com>> wrote: >&

Re: [swift-dev] Having 64-bit swift_retain/release ignore all negative pointer values

> On Oct 13, 2016, at 2:14 PM, Joe Groff via swift-dev > wrote: > > >> On Oct 13, 2016, at 2:04 PM, Alexis wrote: >> >> Correct me if I’m wrong, but aren’t all kernel addresses negative on x64 and >> AArch64? Would this then mean any attempt to use Swift in kernel-space >> requires a disti

Re: [swift-dev] Semantic ARC and enum projection (Re: Having 64-bit swift_retain/release ignore all negative pointer values)

;> On Oct 16, 2016, at 1:10 PM, Dave Abrahams via swift-dev >>>> wrote: >>>> >>>> >>>> on Thu Oct 13 2016, Joe Groff wrote: >>>> >>>>>> On Oct 13, 2016, at 1:18 PM, Greg Parker wrote: >>>>>> >>>

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 19, 2016, at 8:42 PM, Joe Groff via swift-dev > wrote: > I had a discussion with Steve this morning about the potential for enum > layout optimization with floating-point payloads. One great thing about > floating-point is that it has NaNs, and lots of them. For the most part, the > o

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 20, 2016, at 10:50 AM, Joe Groff wrote: >> On Oct 20, 2016, at 10:45 AM, John McCall > > wrote: >> >>> On Oct 19, 2016, at 8:42 PM, Joe Groff via swift-dev >> > wrote: >>> I had a discussion with Steve this morning about the potentia

Re: [swift-dev] Cleaning up stale branches?

> On Oct 21, 2016, at 10:39 AM, Dave Abrahams via swift-dev > wrote: > on Fri Oct 21 2016, Daniel Dunbar wrote: > >> While on this topic... >> >> GitHub's support for doing cross-repo pull requests is >> excellent. Anyone can easily fork the main repo, and push to their >> side repo (for examp

Re: [swift-dev] Cleaning up stale branches?

> On Oct 21, 2016, at 12:23 PM, Daniel Dunbar wrote: >> On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >> on Fri Oct 21 2016, John McCall > > wrote: >> On Oct 21, 2016, at 10:39 AM, Dave Abrahams via sw

Re: [swift-dev] Cleaning up stale branches?

> On Oct 21, 2016, at 1:54 PM, Dave Abrahams wrote: > on Fri Oct 21 2016, John McCall wrote: > >>> On Oct 21, 2016, at 12:23 PM, Daniel Dunbar wrote: On Oct 21, 2016, at 12:14 PM, Dave Abrahams via swift-dev > > wrote: on Fri Oct 21 2016,

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 24, 2016, at 8:49 AM, Joe Groff via swift-dev > wrote: >> On Oct 22, 2016, at 10:39 AM, Chris Lattner wrote: >> >>> On Oct 20, 2016, at 2:59 PM, Joe Groff via swift-dev >>> wrote: copysign( ) is a reason to not pick the first option. I’m not very worried about it, b

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 24, 2016, at 12:30 PM, Stephen Canon wrote: >> On Oct 24, 2016, at 2:55 PM, John McCall via swift-dev >> wrote: >> >>> On Oct 24, 2016, at 8:49 AM, Joe Groff via swift-dev >>> wrote: >>>> On Oct 22, 2016, at 10:39 AM, Chris Latt

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 24, 2016, at 1:07 PM, Jordan Rose wrote: >> On Oct 24, 2016, at 12:58, John McCall via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >>> On Oct 24, 2016, at 12:30 PM, Stephen Canon >> <mailto:sca...@apple.com>> wrote: >>

Re: [swift-dev] Making the sign of NaNs unspecified to enable enum layout optimization

> On Oct 24, 2016, at 1:23 PM, Joe Groff wrote: >> On Oct 24, 2016, at 12:58 PM, John McCall > <mailto:rjmcc...@apple.com>> wrote: >> >>> On Oct 24, 2016, at 12:30 PM, Stephen Canon >> <mailto:sca...@apple.com>> wrote: >>

Re: [swift-dev] SE-0047 - Defaulting non-Void functions so they warn on unused results

> On Oct 30, 2016, at 5:49 AM, Jody Schofield via swift-dev > wrote: > Sorry, I'm sure this has been discussed before, but what the heck??? > > This feature is killing me. Now I have go add @discardableResult to every > function that returns a non-Void or use the ugly syntax `_ =`? > > Until

Re: [swift-dev] Continuation-based versus nested-function-based materializeForSet

> On Oct 31, 2016, at 12:22 PM, Joe Groff via swift-dev > wrote: > We currently abstract over mutable property accesses using what I’ll call a > continuation-based model–the materializeForSet accessor is called before an > inout access, and returns a continuation callback that must be called wh

Re: [swift-dev] Continuation-based versus nested-function-based materializeForSet

> On Nov 2, 2016, at 9:05 AM, Joe Groff via swift-dev > wrote: >> On Nov 1, 2016, at 9:23 PM, Slava Pestov wrote: >> >>> >>> On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev >>> wrote: >>> >>> - Does this help us with the nested dictionary CoW problem? >>> `foo["bar"]["baz"] += 1` >>

Re: [swift-dev] Continuation-based versus nested-function-based materializeForSet

> On Nov 2, 2016, at 11:38 AM, John McCall via swift-dev > wrote: > >> On Nov 2, 2016, at 9:05 AM, Joe Groff via swift-dev >> wrote: >>> On Nov 1, 2016, at 9:23 PM, Slava Pestov wrote: >>> >>>> >>>> On Nov 1, 2016, at 11:0

Re: [swift-dev] [RFC] Modify the build system to enable/disable ObjC interop for any platform

> On Nov 28, 2016, at 1:33 PM, Joe Groff via swift-dev > wrote: >> On Nov 28, 2016, at 7:26 AM, Brian Gesiak via swift-dev >> wrote: >> >> Hello all! >> >> While reviewing https://github.com/apple/swift/pull/5904, I had a crazy >> thought, and I'd like to get some feedback on it. >> >> Here

Re: [swift-dev] Questions about ARC

> On Nov 30, 2016, at 8:33 AM, Jiho Choi via swift-dev > wrote: > Hi, > > I am new to Swift, and I have several questions about how ARC works in Swift. > > 1. I read from one of the previous discussions in the swift-evolution list > (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo

Re: [swift-dev] Questions about ARC

> On Nov 30, 2016, at 11:58 AM, Alexis wrote: >> On Nov 30, 2016, at 12:41 PM, John McCall via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> When we say that we don't have a concurrency model, we mean that (1) we >> aren't providing a

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

> On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev > wrote: >> On Dec 5, 2016, at 4:24 PM, Michael Gottesman via swift-dev >> wrote: >> >> Hello everyone! >> >> This is a proposal for 2 instructions needed to express borrowing via SSA at >> the SIL level. The need for these were discover

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

> 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 >> > wrote: On Dec 5, 2016, at 4:24 PM, Michael Gottesman via swift-dev >

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

> On Dec 7, 2016, at 3:20 PM, Andrew Trick wrote: >> On Dec 7, 2016, at 3:16 PM, Michael Gottesman > <mailto:mgottes...@apple.com>> wrote: >>> On Dec 7, 2016, at 2:52 PM, Andrew Trick via swift-dev >> <mailto:swift-dev@swift.org>> wrote: >>>

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

> 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 online HTML > version of the document is available here: > > https://gottesmm.github.io/proposals/sil-ownership-model.html >

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

> On Dec 8, 2016, at 1:53 PM, Andrew Trick wrote: >> On Dec 7, 2016, at 11:25 PM, John McCall via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >>> >>> On Dec 7, 2016, at 2:13 PM, Michael Gottesman via swift-dev >>> mailto:swift-de

Re: [swift-dev] Questions related to Chris's IBM talk

> On Dec 17, 2016, at 1:25 PM, Nabeel Imtiaz via swift-dev > wrote: > Hi, > > I went through the speaker deck of Chris's talk @ IBM (would be great if > video was also available). What got me really excited, among all other > things, was the the manual memory management part. Particularly beca

  1   2   3   >