Re: [swift-dev] Language Specification on Github?

> On Dec 4, 2015, at 8:23 AM, David Waite wrote: > > Is there a possibility of the swift books (at least the core language and a > html build process ) being turned into projects on github? I do have > changes/fixes which I would suggest against the books if there was a process > to do so - a

Re: [swift-dev] Proof-of-concept port of Swift for Android

On Dec 8, 2015, at 8:50 PM, Zhuowei Z via swift-dev wrote: > I'm currently working on adding support to the Swift compiler to allow it to > target Android. Cool. Responding to one specific issue: > - What's the role of the special linker script, and what's the purpose of the > conformance tab

Re: [swift-dev] Starter project: Convert release notes into something useful

> On Dec 7, 2015, at 4:21 PM, joe via swift-dev wrote: > > Nm my question about the duplicated content, I just noticed after starting to > look into this that some of the notes in the Xcode release notes are the same > as in the CHANGELOG. I'll get started on adding the missing content. Sound

Re: [swift-dev] Question about implementation of closure capture lists

> On Dec 9, 2015, at 8:57 AM, Greg Titus via swift-dev > wrote: > > Hi all, > > I thought I’d take a look at SR-153 "Bad fix suggestion for changing value of > capture list constants" , and I’d > really appreciate it if someone more familiar with the cod

Re: [swift-dev] Radar and bugs.swift.org

> On Dec 9, 2015, at 5:21 PM, Frederick Kellison-Linn via swift-dev > wrote: > > Hi everyone, > > All throughout the Swift codebase there references to Radar bugs (just do a > search for “rdar" on the repo). As far as I am aware, these are all still > private/internal. Is this the case? Yes

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

#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. -Chris > On Dec 11, 2015, at 7:00 AM, Mike Ash via swift-dev > wrote: > > 3. Borrow a bit from the weak poi

Re: [swift-dev] Porting swift to FreeBSD

> On Dec 13, 2015, at 3:34 AM, Davide Italiano via swift-dev > wrote: > > On Sun, Dec 13, 2015 at 6:15 AM, Dmitri Gribenko wrote: >> On Sun, Dec 13, 2015 at 2:52 AM, Davide Italiano >> wrote: >>> And now, swift compiled programs run correctly on FreeBSD! >> >> This is great, thanks Davide!

Re: [swift-dev] Location of "indirect" declaration modifier

On Dec 11, 2015, at 7:03 AM, Slava Pestov via swift-dev wrote: > With your proposal, the fact that the entire tuple payload can be matched by > a pattern implies that ‘indirect’ has to become a formal type in the > language, since you will now be able to write down a value of type '(indirect >

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

> On Dec 14, 2015, at 8:15 PM, Jesse Rusak via swift-dev > wrote: > > Hi all, > > I’m investigating this bug: https://bugs.swift.org/browse/SR-186 > > > Which appears to be a result of the fact that the logic that determines if an > operator is prefix/

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

> On Dec 14, 2015, at 9:51 PM, Simon Pilkington > wrote: > > It seems to make more sense to treat comments as this if they are not present. > > As a related question, should the presence/absence of whitespace be important > at all? It seems fragile if it is. The current design depends on whi

Re: [swift-dev] This little program currently compiles fine, but should it?

> On Dec 15, 2015, at 3:42 PM, Jens Persson via swift-dev > wrote: > > Ok thanks, and what about the initial topic of this thread, ie stuff like > this: > > func f() { > 1; "two"; 3.0 > [4, 5]; 6 * 7 > print("No warnings or errors!") > } > f() // No warnings or errors! > > Should

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

gree with your argument that treating them as whitespace is better, but I don’t feel strongly about it. -Chris > >> On Dec 15, 2015, at 7:15 PM, Jesse Rusak > <mailto:m...@jesserusak.com>> wrote: >> >>>> On Dec 14, 2015, at 9:42 PM, Chris Lattner

Re: [swift-dev] Starter project: SR-2: Build configuration directives can not wrap switch cases

On Dec 17, 2015, at 9:06 AM, Dmitri Gribenko via swift-dev wrote: >> Quick question about this one. >> >> As mentioned in SR-2, the current grammar for switch >> statements [1] does not allow for compiler control >> statements. So, fixing this involves a grammar >> change. >> >> I suspect that

Re: [swift-dev] Starter project: SR-2: Build configuration directives can not wrap switch cases

On Dec 17, 2015, at 10:19 AM, Meador Inge wrote: > >> I suspect that grammar changes will require a proposal > >> on the swift-evo list? > > > > I think this can be treated as a bug fix. > > Agreed, > > Thanks. What is the process for updating the grammar > in the documentation after the bug fi

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

> On Dec 17, 2015, at 3:44 PM, Joe Groff via swift-dev > wrote: > > >> On Dec 17, 2015, at 3:43 PM, Greg Parker wrote: >> >> >>> On Dec 17, 2015, at 3:34 PM, Joe Groff via swift-dev >>> wrote: >>> >>> On ARMv7 and ARM64, the argument and return register sets are the same >> >> Nit: True

[swift-dev] FYI: Apple holiday shutdown

Hi Everyone, Just a head’s up that Apple has a holiday shutdown from Dec 24 to Jan 3 (and many people are already out). The web site, mailing lists and all other services should still be up, but don’t be surprised if there are additional delays in responding to threads and pull requests during

Re: [swift-dev] bugs.swift.org usage

> On Dec 21, 2015, at 8:31 AM, William Dillon via swift-dev > wrote: > > Now that I’ve published a tarball of the ARM swift compiler, I’m getting some > messages about this or that not working. I’m curious about the intended > usage/audience of bugs.apple.com . Shoul

Re: [swift-dev] Reducing the size of Swift binaries by shortening symbols

> On Dec 20, 2015, at 9:53 PM, Dmitri Gribenko via swift-dev > wrote: > >> >> nm -a libswiftCore.dylib > strings.txt >> >> I also have a concern about making mangled names completely unreadable. >> Today, I can frequently at least get a gist of what the referenced entity is >> without a deman

Re: [swift-dev] Including third-party code in repo

On Dec 19, 2015, at 12:26 PM, Zhuowei Z via swift-dev wrote: > I'm currently working on a port of Swift to Android. Great! > Since Android's libc is missing a few required methods, I added code from a > few other sources to implement the functionality. Specifically, I added an > implementatio

Re: [swift-dev] Build failure in LLDB

My fault, I think that ea61c8a should fix it, but I haven’t tested it. Can you please let me know if there is still a problem? Thanks! -Chris > On Jan 1, 2016, at 10:46 AM, Joseph Bell via swift-dev > wrote: > > I've confirmed that the lldb failure is with a pristine build environment as >

Re: [swift-dev] Build failure in LLDB

Thanks! Hopefully ad4d065 will finish it off, -Chris > On Jan 1, 2016, at 11:33 AM, Joseph Bell wrote: > > Chris: > > One error down, a few more: > /lldb/source/Plugins/ExpressionParser/Swift/SwiftPersistentExpressionState.cpp:155:47: > error: member reference type 'llvm::MutableArrayRef' >

Re: [swift-dev] Build failure in LLDB

Fantastic, thanks Joe! -Chris > On Jan 1, 2016, at 2:02 PM, Joseph Bell wrote: > > Confirmed that as of the following revs the world builds and all tests > passing: > > % swift swiftrevs.swift > swift:c264b1eda0d > llvm:3ebdbb2c7e5 > clang:f66c5bb67b9 > lldb:37fa5a942ff > cmark:5af77f3c1d7 >

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

IMO, we should remove/disable this test unless it can be “really” fixed. It is unacceptable to have a test that we know injects noise into our CI systems. Having to second guess whether failures are “real” or not undermines their value, and we should continue to stomp out any nondeterminism fr

Re: [swift-dev] Why are we re-linking?

> On Apr 6, 2016, at 11:08 AM, Jordan Rose via swift-dev > wrote: > > I imagine it's because your git hash has changed, which is used in the > --version output for swiftc. I'm not sure how to avoid that cost entirely, > but we could add a CMake option to not do it (which you could set locally

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

Fixed with 3aa4ff4. -Chris > On Apr 17, 2016, at 12:16 AM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-package-linux-ubuntu-15_10 [#1018] > > Build URL: > https://ci.swift.org/job/oss-swift-package-linux-ubuntu-15_10/1018/ >

Re: [swift-dev] Swift port to Windows : Offering help!

On Apr 20, 2016, at 10:59 PM, Joel Van Eenwyk via swift-dev wrote: > Hi all, > > I'm a very new user of Swift and interested in finding ways to contribute to > the project. I can happily work with the Linux port of the project, but I > have a lot of Windows development experience and would pro

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

Fixed in 7035da2. -Chris > On May 2, 2016, at 9:39 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#4716] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/4716/ >

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

Fixed in 684e660. -Chris > On May 6, 2016, at 9:30 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#3898] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/3898/ > > Project: oss-

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

TypeName.swift failure fixed in 6e423a0. -Chris > On May 6, 2016, at 9:33 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#4613] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/4613/ >

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

On May 11, 2016, at 8:17 PM, Russ Bishop via swift-dev wrote: > >> On May 11, 2016, at 4:50 PM, Dmitri Gribenko wrote: >> >> On Wed, May 11, 2016 at 2:53 PM, Russ Bishop via swift-dev >> wrote: >>> I’m implementing SE-0017 but based on the standard library guidelines I >>> think Unmanaged sh

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

> 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 UnsafeBytePointer proposal. If >> we accept that, it will separate UnsafePointer into its own type. >> >> -Joe

Re: [swift-dev] Argument unused warnings

> On May 17, 2016, at 1:25 PM, Dmitri Gribenko via swift-dev > wrote: > > On Tue, May 17, 2016 at 12:37 PM, Daniel Dunbar via swift-dev > wrote: >> Something broke yesterday causing Swift to report gobs of argument unused >> warnings, see: >> https://bugs.swift.org/browse/SR-1546 >> for a re

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 w

Re: [swift-dev] [swift-evolution] Possible bug with arithmetic optional comparison ?

> On May 24, 2016, at 9:35 AM, Jordan Rose via swift-dev > wrote: > > I wouldn’t phrase it this way. “nil” could just as easily been above all of > the integers. > > We added overloads for < and friends that took optionals so that you could > sort an array by passing < and get something reas

Re: [swift-dev] [swift-evolution] Possible bug with arithmetic optional comparison ?

> On May 24, 2016, at 11:14 AM, Joe Pamer wrote: > >>> >>> On May 24, 2016, at 9:35 AM, Jordan Rose via swift-dev >> > wrote: >>> >>> I wouldn’t phrase it this way. “nil” could just as easily been above all of >>> the integers. >>> >>> We added overloads for < and

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

Fixing. -Chris > On May 30, 2016, at 3:48 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-osx [#4321] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/4321/ > > Project: oss-swift-inc

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

Should be fixed in 87db7b4. -Chris > On Jul 2, 2016, at 4:50 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6172] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6172/ >

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

Fixed in 2abc92b. -Chris > On Jul 3, 2016, at 4:18 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6186] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6186/ >

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

Fixed harder in 0296316. -Chris > On Jul 17, 2016, at 12:59 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6558] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/6558/ >

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

Fixed in b4cba58. -Chris > On Jul 17, 2016, at 3:40 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#6305] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6305/ >

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

Not really sure what is going on here, but this isn’t due to my patch afaict. -Chris > On Jul 23, 2016, at 5:55 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#6763] > > Build URL: > https://ci.swift.org/job/oss-swift-increment

Re: [swift-dev] [Swift Code Owners] new code owner for the SIL optimizer

> On Jul 22, 2016, at 3:59 PM, Bob Wilson wrote: > > CODE_OWNERS.TXT still shows Nadav as the owner of the SIL optimizer, even > though he is no longer working on Swift. We should have a new code owner, and > I would like to nominate Erik Eckstein. There are a lot of different > components to

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

> On Jul 27, 2016, at 12:45 PM, Slava Pestov via swift-evolution > wrote: > > >> On Jul 27, 2016, at 12:38 PM, Ted Kremenek via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >> SE-0092 - Typealiases in protocols and protocol extensions >>

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

Not mine, -Chris > On Jul 29, 2016, at 4:59 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-osx [#5601] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/5601/ > > Pro

Re: [swift-dev] [swift-evolution] [Swift 4] Organizing source stability

> On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Chris writes: > - Source stability features: These should be relatively small, but important. > For example, we need a “-std=swift3” sort of compiler flag. We may also add > a way to conditionally enable lar

Re: [swift-dev] [swift-evolution] [Swift 4] Organizing source stability

> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch wrote: > > Here are a few thoughts: > -swift=4 > -swift-version=4 -swift-version seems like the best option to me, but Jordan will have a strong opinion. I think he’s crazy busy with Swift 3 work until late next week. -Chris > -language-ve

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

Fixing. Validation tests shouldn’t check diagnostics. -Chris > On Jul 31, 2016, at 4:47 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-15_10 [#7028] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-15_10/7028/ >

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

Fixed in 156b9bb -Chris > On Jul 31, 2016, at 5:27 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-14_04 [#6656] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/6656/ >

Re: [swift-dev] Question about size of Character type

> On Aug 19, 2016, at 6:22 PM, Slava Pestov via swift-dev > wrote: > > >> On Aug 19, 2016, at 2:04 PM, Jordan Rose via swift-dev > > wrote: >> >> We have an old Radar about this, rdar://problem/16754935 >> . It's probably just a case we're missing in enum >> layo

Re: [swift-dev] What about concurrency?

On Sep 4, 2016, at 3:00 PM, Anton Mironov via swift-dev wrote: > > My job is mostly consists of writing core functionality for macOS (and I love > core functionality). My code must take advantage of concurrency. I've been > looking for solutions that allow me to write clean and (most important

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

> On Oct 7, 2016, at 2:38 PM, Michael Gottesman via swift-dev > 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 11, 2016, at 10:10 AM, Michael Gottesman wrote: >> >If ARC Code Motion wishes to move the ARC semantics of ownership qualified >> >load, store instructions, it must now consider read/write effects. On the >> >other hand, it will be able to now not consider the side-effects of >> >destruc

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

> 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, but it is a reason. I see no problem with the second option. > > As we discussed in person this morning, de-canonicalizing b11 might b

[swift-dev] Update on the Swift Project Lead

Since Apple launched Swift at WWDC 2014, the Swift team has worked closely with our developer community. When we made Swift open source and launched Swift.org we put a lot of effort into defining a strong community structure. This structure has enabled Apple and the amazingly vibrant Swift co

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

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

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

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

Re: [swift-dev] [Discuss] Remove SwiftExperimental

> On Jul 19, 2017, at 1:23 PM, Robert Widmann via swift-dev > wrote: > > Hello all, > > The SwiftExperimental > > library’s stated purpose is to be a place where experimental library > fea

Re: [swift-dev] [Discuss] Remove SwiftExperimental

> On Jul 21, 2017, at 8:57 AM, Joe Groff wrote: > > > > On Jul 20, 2017, at 12:54 PM, Chris Lattner via swift-dev > mailto:swift-dev@swift.org>> wrote: > >> >>> On Jul 19, 2017, at 1:23 PM, Robert Widmann via swift-dev >>> mai

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

> On Jul 28, 2017, at 3:59 PM, Jordan Rose via swift-dev > wrote: > >>> So generic code to instantiate type metadata would have to construct these >>> mangled strings eagerly? >> >> We already do exactly that for the ObjC runtime name of generic class >> instantiations, for what it's worth,

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: > > Overall, my intuition is that the tradeoffs come out in favor for nonunique > metadata objects, but what do you all think? Is there anything I'm missing? I think your proposal makes sense, particularly when we start caring about

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

> On Jul 29, 2017, at 1:32 PM, John McCall wrote: > >> On Jul 29, 2017, at 4:24 PM, Chris Lattner via swift-dev >> wrote: >> >> On Jul 28, 2017, at 2:20 PM, Joe Groff via swift-dev >> wrote: >>> >>> Overall, my intuition is that the t

[swift-dev] Reducing array abstraction

This question is somewhere between swift-dev and swift-users, not sure where best to post this. I’m working on a project that wants to get very low-abstraction penalty array operations, particularly with varargs. Given the currently language limitations (no fixed size arrays), the best I’ve

Re: [swift-dev] Reducing array abstraction

On Oct 6, 2017, at 11:12 PM, Slava Pestov wrote: >> On Oct 6, 2017, at 11:06 PM, Chris Lattner via swift-dev >> wrote: >> This question is somewhere between swift-dev and swift-users, not sure where >> best to post this. >> >> I’m working on a project th

Re: [swift-dev] Reducing array abstraction

> On Oct 8, 2017, at 11:57 AM, Michael Gottesman via swift-dev > wrote: > > >> On Oct 6, 2017, at 11:06 PM, Chris Lattner via swift-dev >> wrote: >> >> This question is somewhere between swift-dev and swift-users, not sure where >> best to post th

Re: [swift-dev] Reducing array abstraction

On Oct 8, 2017, at 3:30 PM, Erik Eckstein wrote: >>> We definitely already have a heap->stack for classes in the guise of the >>> StackPromotion optimization is that what you are talking about with the >>> "array outlining" optimization? (outlining to me is referring to >>> specifically code ou

Re: [swift-dev] Reducing array abstraction

On Oct 9, 2017, at 9:55 PM, Slava Pestov via swift-dev wrote: >> On Oct 7, 2017, at 2:01 PM, Chris Lattner wrote: >> Right. If we ignore source compatibility for the moment, it seems clear >> that the best callee side representation for varargs is a borrowing array >> slice (like llvm::ArrayR

Re: [swift-dev] Reducing array abstraction

> On Oct 10, 2017, at 9:50 AM, Erik Eckstein wrote: > > > >> On Oct 9, 2017, at 9:46 PM, Chris Lattner > > wrote: >> >> On Oct 8, 2017, at 3:30 PM, Erik Eckstein > > wrote: > We definitely already have a heap->stack for classes in th

Re: [swift-dev] sharing tips and tricks and scripts

Any scripts should be subject to the same code review and design policies as the rest of the compiler. A bisection script or build-script seem fine, but a four line script to automate something is probably not the right thing to include. -Chris > On Oct 17, 2017, at 6:05 PM, Jordan Rose via s

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 11:44 PM, Xiaodi Wu via swift-dev > wrote: > > On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull > wrote: > One completely different idea, which I brought up a year or so ago, is to do > what we do with pointers around this. That is you have your fas

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

On Oct 31, 2017, at 9:07 AM, Stephen Canon via swift-dev wrote: > [Replying to the thread as a whole] > > There have been a bunch of suggestions for variants of `==` that either trap > on NaN or return `Bool?`. I think that these suggestions result from people > getting tunnel-vision on the id

Re: [swift-dev] deprecating -Ounchecked

> On Nov 2, 2017, at 9:52 AM, Erik Eckstein via swift-dev > wrote: > > Hi, > > I’d like to propose to deprecate the -Ounchecked swift optimization mode. > > The -Ounchecked mode actually contradicts one of the main goals of swift: to > be a safe language. > In the past we didn’t see lot of s

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Nov 1, 2017, at 9:16 AM, Ben Cohen via swift-dev > wrote: > > > >> On Oct 31, 2017, at 10:11 PM, Chris Lattner via swift-dev >> wrote: >> >> On Oct 31, 2017, at 9:07 AM, Stephen Canon via swift-dev >> wrote: >>> [Replying to t

Re: [swift-dev] deprecating -Ounchecked

On Nov 3, 2017, at 8:31 AM, Erik Eckstein via swift-dev wrote: >>> >>> Deprecating would mean that we map -Ounchecked to -O. >>> >>> If you have any comments or concerns, please let me know >> >> What’s the motivation for this? What problem does it solve? > > There are several issues: > Firs

Re: [swift-dev] deprecating -Ounchecked

> On Nov 3, 2017, at 10:23 PM, Slava Pestov via swift-dev > wrote: > > > >> On Nov 3, 2017, at 8:57 PM, Chris Lattner via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Random question: when did you introduce -Osize, and why didn’t it g

Re: [swift-dev] deprecating -Ounchecked

> On Nov 4, 2017, at 9:52 PM, Erik Eckstein wrote: >>> Are compiler flags within the scope of the evolution process? -Osize has no >>> effect on source compatibility or any other user-visible aspect of the >>> language itself. >> >> I don’t think there is an official policy, but IMO, all major

Re: [swift-dev] deprecating -Ounchecked

> On Nov 12, 2017, at 3:25 PM, Ted Kremenek via swift-dev > wrote: > > The compiler flags have user impact because people use them. I am mixed on > whether every flag change needs to go through an evolution proposal, but in > this case because it is tied with the fate of this language mode

Re: [swift-dev] [Swift CI] Build Failure: 2. Swift Source Compatibility Suite (master) #806

Not it: -Chris In file included from /Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/swift/lib/Migrator/Migrator.cpp:13: In file included from /Users/buildnode/jenkins/workspace-private/swift-master-source-compat-suite/swift/include/swift/Frontend/Frontend.h:35: In f

Re: [swift-dev] Default deployment target for swiftc

+1 -Chris > On Nov 28, 2017, at 10:36 AM, Tony Allevato via swift-dev > wrote: > > I agree, the currently running OS seems like the right default here. > Progressive disclosure and ease of prototyping are good motivations here. If > I just want to quickly prototype something, I'm not going t

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

This isn’t related to my patch. Artem? -Chris > On Dec 21, 2017, at 5:18 PM, swift...@swift.org wrote: > > [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#2101] > > Build URL: > https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-16_10/2101/ >

Re: [swift-dev] [arc optimization] Why doesn't enum destructuring use guaranteed references?

This is a great question, I’m not sure what the answer is: maybe it is a simple case missed by the arc optimizer? -Chris > On Dec 27, 2017, at 9:19 PM, Félix Cloutier via swift-evolution > wrote: > > Running this on my MBP with 10 as the parameter: > https://gist.github.com/zneak/ae33bb9

[swift-dev] "available externally" vs build time

Folks working on the SIL optimizer, particularly those interested in faster builds: If I understand the SIL optimizer correctly, it seems that when the current program references an external symbol declared as @_inlinable, that SILModule::linkFunction eagerly deserializes the @_inlinable body a

Re: [swift-dev] "available externally" vs build time

> On Jan 4, 2018, at 1:08 PM, Erik Eckstein wrote: >>> 1. It looks like the MandatoryInliner is the biggest culprit at -O0 here: >>> it deserializes the referenced function (MandatoryInlining.cpp:384) and >>> *then* checks to see if the callee is @_transparent. Would it make sense >>> to chang

Re: [swift-dev] "available externally" vs build time

> On Jan 4, 2018, at 2:11 PM, Erik Eckstein via swift-dev > wrote: > >>> >>> Well, with our pass pipeline architecture I suspect it will not make a >>> difference. We process functions bottom-up. For example, the performance >>> inliner optimizes the callee first before trying to inline it (

Re: [swift-dev] "Swift 4.1 or Swift 3.3"

> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev > wrote: > > Hi, all. Swift 4.1 is off on its own branch and going well, but we never > quite came up with an answer for a particular problem developers might have: > "am I running a Swift 4.1 compiler?”. I agree, this is getting bad.

Re: [swift-dev] "Swift 4.1 or Swift 3.3"

On Jan 8, 2018, at 5:26 PM, Jordan Rose via swift-dev wrote: >> On Jan 8, 2018, at 17:18, Chris Lattner > > wrote: >>> On Jan 5, 2018, at 4:19 PM, Jordan Rose via swift-dev >> > wrote: >>> >>> Hi, all. Swift 4.1 is off on its own branch and

Re: [swift-dev] State of String: ABI & Performance

On Jan 10, 2018, at 11:55 AM, Michael Ilseman via swift-dev wrote: > (A gist-formatted version of this email can be found at > https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f > ) I’m very very excited for this

Re: [swift-dev] State of String: ABI & Performance

> On Jan 10, 2018, at 9:29 PM, Chris Lattner wrote: > > On Jan 10, 2018, at 11:55 AM, Michael Ilseman via swift-dev > mailto:swift-dev@swift.org>> wrote: >> (A gist-formatted version of this email can be found at >> https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f >>

Re: [swift-dev] State of String: ABI & Performance

Thanks Ole, that’s definitely nicer, I’ve updated my code! Still not exactly ergonomic though :-) -Chris > On Jan 11, 2018, at 3:28 AM, Ole Begemann via swift-dev > wrote: > > > > In this particular example, you can use UInt8.init(ascii:) to make it a > little nicer (no need for the charTo

Re: [swift-dev] State of String: ABI & Performance

On Jan 11, 2018, at 12:32 PM, Michael Ilseman wrote: >>> We may also want a compact 5-bit encoding for formatted numbers, such as >>> 64-bit memory addresses in hex, `Int.max` in base-10, and `Double` in >>> base-10, which would require 18, 19, and 24 characters respectively. 120 >>> bits with

Re: [swift-dev] State of String: Ergonomics, and You!

On Jan 10, 2018, at 11:55 AM, Michael Ilseman via swift-dev wrote: > ## String Ergonomics > > Ergonomics is an area that’s not been well-served by String. Collection > conformance and multi-line literals in Swift 4 were a welcome first step. > But, trying to write a script, solve a classic whi

Re: [swift-dev] State of String: Ergonomics, and You!

> On Jan 13, 2018, at 10:30 AM, Michael Ilseman via swift-dev > wrote: >> I wouldn’t overly rely on it for guidance on these issues give that it it >> stuck so squarely in the realm of UTF16. >> > > Wading a little into the weeds here, CharacterSet’s builtins model older > Unicode semantics