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

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. Michael > On Dec 12, 2015, at 3:15 PM, Jacob Bandes-Storch via swift-dev > wrote

[swift-dev] [Starter Project] Teach SILParser how to parse switch_enum of undef.

This is a small starter project for those who are interested in working with SIL. The SIL Parser currently is unable to parse switch_enum of undef. I wrote a patch that does the work some time ago, but I never have had time to finish it (i.e. make sure everything works ok/write tests). I posted

Re: [swift-dev] [Starter Project] Teach SILParser how to parse switch_enum of undef.

to claim this. I've assigned issue SR-210 to > myself. > > --Emanuel > > On Sun, Dec 13, 2015 at 1:29 PM, Michael Gottesman via swift-dev > mailto:swift-dev@swift.org>> wrote: > This is a small starter project for those who are interested in working with > SIL. >

Re: [swift-dev] [Starter Project] Teach SILParser how to parse switch_enum of undef.

bugs.swift.org/browse/SR-247> > > Michael > >> On Dec 16, 2015, at 5:30 AM, Emanuel Zephir > <mailto:emanuelzep...@gmail.com>> wrote: >> >> Unless anyone objects, I'd like to claim this. I've assigned issue SR-210 to >> myself. >> >>

Re: [swift-dev] [Starter Project] Teach SILParser how to parse switch_enum of undef.

consider moving it into its own file if it is possible. Michael > On Dec 22, 2015, at 12:02 PM, Davide Italiano wrote: > > > > On Sun, Dec 13, 2015 at 4:29 PM, Michael Gottesman via swift-dev > mailto:swift-dev@swift.org>> wrote: > This is a small starter project f

Re: [swift-dev] [Starter Project] Teach SILParser how to parse switch_enum of undef.

You know what, let me file some bugs. I just thought of some more. > On Dec 22, 2015, at 1:45 PM, Michael Gottesman via swift-dev > wrote: > > Here are some off the top of my head. Many are related to code quality. Tell > me what you think: > > 1. We have recently

Re: [swift-dev] [Starter Project] Teach SILParser how to parse switch_enum of undef.

://bugs.swift.org/browse/SR-342 > On Dec 22, 2015, at 1:48 PM, Michael Gottesman via swift-dev > wrote: > > You know what, let me file some bugs. I just thought of some more. > >> On Dec 22, 2015, at 1:45 PM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>>

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

One form of overloading that we currently have at the SIL level are the notions of the "unowned" calling convention and "unowned" the variable ownership convention. For those who are unfamiliar with the unowned calling convention consider the following: @tmp : $@convention(thin) (@owned Array,

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

> On Jan 4, 2016, at 4:35 PM, Michael Gottesman wrote: > > The name doesn't really matter to me TBH (and as you can tell I am not an > expert at such things like Jordan). > > I just dislike having this Sorry for the cut off sentence. John/Jordan, do you have any naming thoughts? Michael >

Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on Pi from source

+CC Lang Hames (Just in case) > On Apr 15, 2016, at 6:45 PM, Joe Groff via swift-dev > wrote: > >> >> On Apr 15, 2016, at 1:24 PM, Timothy Wood via swift-dev >> wrote: >> >> >> I was able to get Swift running on my Raspberry Pi using a variant of the >> instructions at >>

Re: [swift-dev] R_ARM_GOT_PREL error when building Swift on Pi from source

ee/arm> > > I haven't had time to upstream the changes to LLVM. I am not actually involved in this discussion beyond ensuring that Lang who works in this area is aware of it. > > - Will > >> On Apr 16, 2016, at 1:49 PM, Michael Gottesman via swift-dev >> mail

Re: [swift-dev] Ubuntu 14.04 Swift master build failure

For 14.04, you need to upgrade your CMake. Since we are going to be updating to 3.4.3, I would suggest just doing that. Michael > On Jun 28, 2016, at 7:59 PM, Joseph Bell wrote: > > On 14.04 I can reproduce this, which is also referenced in > https://bugs.swift.org/browse/SR-1923

Re: [swift-dev] Ubuntu 14.04 Swift master build failure

No worries. I actually sent out an email earlier this week with an RFC, but I sent it by mistake to swift-dev@$APPLE instead of swift-dev@swift.org. Sorry about that! Michael > On Jun 29, 2016, at 5:55 AM, Joseph Bell wrote: > > CMake has been upgraded to 3.4.3 on Ubuntu 14.04 and it's now co

[swift-dev] [RFC] Requiring CMake 3.4.3 by Prerequisite.

For a long time, we have been using CMake 2.8.*. This is an RFC to make it a pre-requisite to have cmake 3.4.3 matching LLVM. The reason to do this is: 1. It will make it easier to cherry-pick upstream llvm changes that may require CMake 3.4.3 features into Swift's cmake system. 2. It allows us

[swift-dev] Master-Next bots are now on the public ci

Just an update for everyone. Mishal just put the open source master-next bots on the public ci: https://ci.swift.org/view/swift-master-next/ We are currently in the middle of an update so everything is not blue yet. But a great step forward and a round of applause from me. Thanks Mishal! Micha

Re: [swift-dev] [RFC] Requiring CMake 3.4.3 by Prerequisite.

; > with 3.4.3 in all of the various CMakeLists.txt files? > > Joe > > > On Wed, Jun 29, 2016 at 12:13 PM, Michael Gottesman via swift-dev > mailto:swift-dev@swift.org>> wrote: > For a long time, we have been using CMake 2.8.*. This is an RFC to make it a > pre-r

Re: [swift-dev] [RFC] Requiring CMake 3.4.3 by Prerequisite.

I am now flipping the switch to require the upgraded cmake. Michael > On Jun 30, 2016, at 3:24 PM, Michael Gottesman via swift-dev > wrote: > > Yes. > >> On Jun 30, 2016, at 2:47 PM, Joseph Bell > <mailto:j...@iachieved.it>> wrote: >> >> Michael,

Re: [swift-dev] [RFC] Requiring CMake 3.4.3 by Prerequisite.

To g...@github.com:apple/swift.git ffcafd7..4598b9e master -> master > On Jul 2, 2016, at 10:01 PM, Michael Gottesman wrote: > > I am now flipping the switch to require the upgraded cmake. > > Michael > >> On Jun 30, 2016, at 3:24 PM, Michael Gottesman via swi

Re: [swift-dev] Descriptive Protocol non-conformance errors

I have wanted this for a long time. (In fact I believe I filed a radar some time ago for this!) Filling in the interface stubs saves so much time! Michael > On Jul 6, 2016, at 8:40 PM, Xi Ge via swift-dev wrote: > >> >> On Jul 6, 2016, at 8:24 PM, Douglas Gregor via swift-dev >> wrote: >>

Re: [swift-dev] Unsupported imported target type MODULE_LIBRARY

I am preparing a fix. Its in this PR: https://github.com/apple/swift/pull/3406 Michael > On Jul 7, 2016, at 4:30 PM, David Farler wrote: > > Adding +Michael Gottesman who changed some things around in this file. I also > hit this with: > > build-script -r --debug-swift -x > > CMake Error at

Re: [swift-dev] Optimal Work Flow

> On Jul 8, 2016, at 10:17 AM, Lau Bao via swift-dev > wrote: > > Hi everyone , > I am new the the mailing list and am trying to figure out a optimal work > flow. > I am currently making a change in the stdlib and building the tool chain > through the (swift/utils/build-toolchain) and debug

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

I reverted all the things. The patient should feel better soon. HTH, Dr. G > On Jul 18, 2016, at 4:56 PM, Bob Wilson via swift-dev > wrote: > > + Dave > >> On Jul 18, 2016, at 4:55 PM, Mark Lacey > > wrote: >> >>> >>> On Jul 18, 2016, at 4:43 PM, Bob Wilson via

[swift-dev] Turns out Incremental builds were not actually incremental

Given the backup in the CI, I started looking at what was going on there and I found that the following incremental bots were actually /NOT/ incremental: 1. OS X Swift incremental. 2. 14.04 Linux Swift incremental. 3. 15.10 Linux Swift incremental. 4. OSX LLDB incremental This is in addition to

Re: [swift-dev] Could not find a package configuration file provided by "Clang"

Yes. 3.4.3. Michael > On Jul 21, 2016, at 8:37 AM, Arnold Schwaighofer via swift-dev > wrote: > > Somewhat wild guess. What is the version of your cmake install? > > I think we started requiring some 3ish version recently. > > Maybe you need a newer version … > >> On Jul 20, 2016, at 2:07 P

Re: [swift-dev] Turns out Incremental builds were not actually incremental

Michael > > Jordan > > >> On Jul 19, 2016, at 09:32, Michael Gottesman via swift-dev >> wrote: >> >> Given the backup in the CI, I started looking at what was going on there and >> I found that the following incremental bots were actually /NOT/ increme

Re: [swift-dev] Turns out Incremental builds were not actually incremental

I believe we do trash the module cache folder. > On Jul 21, 2016, at 3:46 PM, Jordan Rose wrote: > > >> On Jul 21, 2016, at 15:06, Michael Gottesman wrote: >> >> >>> On Jul 21, 2016, at 2:54 PM, Jordan Rose wrote: >>> >>> IIRC this was deliberate because of some past issues with things not

Re: [swift-dev] Could not find a package configuration file provided by "Clang"

It is partially my fault TBH. I still need to bump the version check in CMake. We run into a JIT failure when I do this on Linux I believe due to the way ELF forwards symbols (and my needing to work around it). I have not had the time to fix it. = /. If that was set, you would have gotten a nic

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

Can you revert? This is making the linux smoke tests fail. Michael > On Jul 28, 2016, at 6:58 PM, Anders Bertelrud via swift-dev > wrote: > > I am investigating why 6f0b1047d51e6260967ad06e9ded1fa905d508f4 doesn't seem > to have fixed this. > > Anders > > On Jul 28, 2016, at 18:30, no-re...

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

Thanks! I really appreciate it = ). Michael > On Jul 28, 2016, at 9:51 PM, Anders Bertelrud wrote: > > Pushed a revert until I can figure out why it isn't working. > > Anders > >> On 2016-07-28, at 21.42, Michael Gottesman > > wrote: >> >> Can you revert? This is

[swift-dev] Initial smoke test PR message confusion

Hey everyone. >From talking with various people I think there is some confusion around the >initial message shown in the PR test state when one creates a PR. >Specifically, initially the PR test state says something like this: This does not mean that tests have started to be run automatically

Re: [swift-dev] Initial smoke test PR message confusion

ote: > > Do we have control of this message? Can we change the heading to something > like “Please run required checks”. > >> On Jul 28, 2016, at 10:40 PM, Michael Gottesman via swift-dev >> wrote: >> >> Hey everyone. >> >> From talking with variou

Re: [swift-dev] Swift CI: Pull Request Check Status

> On Aug 26, 2016, at 9:50 PM, Ted Kremenek via swift-dev > wrote: > > Awesome! Thanks Mishal! > > Do we have a persistent place where we are documenting these options? I created a file in docs called ContinuousIntegration.md. That is where these should be documented (I think jtbandes updat

[swift-dev] Updating llvm/clang stable branches

Hello swift-dev! We are going to be performing an update to the llvm/clang stable branches within the next couple of days. I will send out an email before I pull the trigger. We will be using a -s ours merge so if you run update-checkout (or even just git pull), everything should fast forward a

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

Why wasn't this caught by pull request testing? Michael > On Aug 31, 2016, at 3:56 PM, Philippe Hausler via swift-dev > wrote: > > Those tests have been disabled by > https://github.com/apple/swift-corelibs-foundation/commit/b98f8d67071b0af39f85c589dfd6cb54ff7c06cd > >

Re: [swift-dev] CI outage

FYI, the tree will actually be locked until Sunday evening. This is so that we can perform the necessary steps to move swift to run on a newer LLVM/Clang, as announced last week. Michael > On Sep 9, 2016, at 10:49 AM, Nicole Jacque via swift-dev > wrote: > > Due to an HVAC maintenance outage

Re: [swift-dev] CI outage

problems! Enjoy! Michael > On Sep 9, 2016, at 4:18 PM, mishal_shah wrote: > > Master has been locked, we will send out another email once its open again. > > Thanks, > Mishal Shah >> On Sep 9, 2016, at 3:39 PM, Michael Gottesman via swift-dev >> wrote: >>

Re: [swift-dev] CI outage

*Also* I would suggest cleaning all of your build directories. There are some cmake changes in LLVM that require a cleaned workspace for Swift to compile against it. Michael > On Sep 11, 2016, at 11:35 PM, Michael Gottesman via swift-dev > wrote: > > The master-next transit

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

This is happening again... https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-14_04/7457/consoleFull#-1007744702ee1a197b-acac-4b17-83cf-a53b95139a76 Is this due to a faulty node? Michael > On Sep 14, 2016, at 11:40 PM, Douglas Gregor via swift-dev > wrote: > > Bad file descriptor

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

> On Sep 15, 2016, at 10:54 PM, Xin Tong wrote: > > >> On Sep 15, 2016, at 10:49 PM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> This is happening again... >> >> https://ci.swift.org/job/oss-swift

Re: [swift-dev] NSXMLNode.swift: error: integer literal overflows when stored into Int

> On Sep 16, 2016, at 4:37 PM, Eric Wing via swift-dev > wrote: > > I'm trying to build Swift 3 for Raspberry Pi 2/armv7. > > I'm currently hitting a compile error at: > > Foundation/NSXMLNode.swift:86:351: error: integer literal '4293918720' > overflows when stored into 'Int'. > > public st

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

I would appreciate it if you would do so = ). This is I imagine blocking @swift-ci testing. Michael > On Sep 17, 2016, at 12:43 AM, Ankit Aggarwal via swift-dev > wrote: > > This has been randomly failing a lot and I can't reproduce locally, Should I > disable this test for now? > > fatal e

Re: [swift-dev] Swift CI PR builder dispatch linux failure

+CC Mishal > On Sep 21, 2016, at 6:59 AM, David P Grove via swift-dev > wrote: > > I don't know how the PR jobs are setup, but the error suggests that they are > trying to reuse too much of the workspace of previous runs. > > :0: error: module file was created by an older version of the > co

[swift-dev] Separating ./docs into several folders

Over time as the project grows, we are going to need more documentation around CI/policy. Right now we just throw both CI/design docs/policy things into ./docs. This makes the docs less organized and less discoverable. My feeling is we would want to separate the docs into: ./design - This would

Re: [swift-dev] Separating ./docs into several folders

> On Sep 22, 2016, at 6:45 PM, Jacob Bandes-Storch wrote: > > Can we get swift.org <http://swift.org/> hosted on GitHub Pages, and then > make these documents part of the main site? :-) That is a different topic, no? ; p. > On Thu, Sep 22, 2016 at 2:59 PM Michael Go

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 14.04 - Long Test (swift 3.0) #302

> On Sep 23, 2016, at 10:02 AM, Jordan Rose via swift-dev > wrote: > >> Foundation/NSData.swift:19:8: error: module file was created by an older >> version of the compiler; rebuild 'Dispatch' and try again: >> /home/buildnode/jenkins/workspace/oss-swift-3.0-incremental-RA-linux-ubuntu-14_04-l

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 14.04 - Long Test (swift 3.0) #302

suggesting? Michael > > - Daniel > >> On Sep 24, 2016, at 7:57 PM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >>> On Sep 23, 2016, at 10:02 AM, Jordan Rose via swift-dev >>> mailto:swift-dev@swift.o

Re: [swift-dev] [Swift CI] Build Still Failing: 0. OSS - Swift Incremental RA - Ubuntu 14.04 - Long Test (swift 3.0) #302

d not work here given that we are talking about dependencies in between Swift's cmake build and ilbdispatch's build. > > I haven't kept up with how libdispatch is built, I assumed it was using a > custom build process like Foundation and XCTest. > > - Daniel > >

Re: [swift-dev] Swift CI PR builder dispatch linux failure

> On Sep 25, 2016, at 11:38 AM, David P Grove via swift-dev > wrote: > > The order may need to vary by platform. On Linux, the DIspatch Swift overlay > code lives in swift-corelibs-libdispatch/src/swift. So it works to build (1) > Swift (2) libdispatch (both C and Swift) (3) Foundation. > Q

Re: [swift-dev] Swift CI PR builder dispatch linux failure

Well in that case, isn't the obvious answer to move the libdispatch linux overlay into the swift? Michael > On Sep 26, 2016, at 1:23 PM, Jordan Rose via swift-dev > wrote: > > The problem with moving the Darwin Dispatch overlay there is that other > overlays depend on Dispatch, and we’re not

[swift-dev] [semantic-arc] High Level Vision

Hello everyone. Below is an introductory high level proposal for Semantic ARC. It attempts to lay out the "vision" without going into too many details. The details will be provided in subsequent mini proposals. The first mini proposal (High Level ARC Memory Operations) has been sent out in a s

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

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 URL: https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html

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

> On Oct 4, 2016, at 1:04 PM, John McCall wrote: > >> >> On Sep 30, 2016, at 11:54 PM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> The document attached below contains the first "Semantic ARC" mini proposa

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

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

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

: $@convention(thin) (@owned C) -> () apply %useC_func(%c2) : $@convention(thin) (@owned C) -> () (7) %d2 = load [take] %global_d : $*D (5) %useD_func = function_ref @useD : $@convention(thin) (@owned D) -> (

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

is operation as a `load [copy]` instruction. Lets define the >> `load >> [copy]` instruction as follows: >> >> %1 = load [copy] %0 : $*C >> >> => >> >> %1 = load %0 : $*C >> retain_value %1 : $C >> >>

Re: [swift-dev] @swift-ci now supports clean workspace for "smoke test" and "test and merge"

I added a section explaining what a smoke test is. Can you add a section describing what a clean smoke test is as well? > On Oct 7, 2016, at 5:24 PM, mishal_shah via swift-dev > wrote: > > Hi Enrico, > > Here is the doc for CI: > https://github.com/apple/swift/blob/master/docs/ContinuousInteg

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

> On Oct 7, 2016, at 9:25 PM, Andrew Trick wrote: > > >> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >>> I wonder whether it might make more sense for load [borrow] to be a >>> diff

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

>> wrote: >>> >>> >>>> On Oct 7, 2016, at 6:04 PM, Michael Gottesman via swift-dev >>>> mailto:swift-dev@swift.org>> wrote: >>>> >>>>> I wonder whether it might make more sense for load [borrow] to be a >>>>&

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

> On Oct 8, 2016, at 10:09 AM, Karl via swift-dev wrote: > > Could you add this (and John’s previous writeup) to the docs in the repo? > > I was reasonably along the way to adding unowned optionals a while back but > got totally lost in SILGen. > This info looks really valuable, but personally

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

> On Oct 10, 2016, at 8:05 PM, Chris Lattner wrote: > > >> On Oct 7, 2016, at 2:38 PM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> Attached below is an updated version of the proposal. Again a rendered

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

> > > :orphan: > > .. highlight:: sil > > === > Copy-On-Write Representation in SIL > === > > .. contents:: > > Overview > > > This document proposes: > > - An ownership attribute to define copy-on-write (COW) buff

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

> On Oct 12, 2016, at 4:36 PM, John McCall via swift-dev > wrote: > >> 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 Gr

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

Attached below is a final version of the proposal. I am going to commit it to the repo if there are no further questions/changes/etc. > https://gottesmm.github.io/proposals/high-level-arc-memory-operations.html > Michae

[swift-dev] [proposa] High Level ARC Value Operations

Hello everyone. Attached below inline is a proposal for High Level ARC Value operations. Additionally a formatted version of this proposal is available here: https://gottesmm.github.io/proposals/high-level-arc-value-operations.html

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

> On Oct 17, 2016, at 9:42 AM, Joe Groff via swift-dev > wrote: > > >> 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: > On Oct 13, 2016, at 10:46 AM,

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

> On Oct 17, 2016, at 10:00 AM, Joe Groff wrote: > > >> On Oct 17, 2016, at 9:57 AM, Michael Gottesman wrote: >> >> >>> On Oct 17, 2016, at 9:42 AM, Joe Groff via swift-dev >>> wrote: >>> >>> On Oct 16, 2016, at 1:10 PM, Dave Abrahams via swift-dev wrote: on

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

> On Oct 17, 2016, at 11:53 AM, Michael Gottesman via swift-dev > wrote: > > >> On Oct 17, 2016, at 10:00 AM, Joe Groff > <mailto:jgr...@apple.com>> wrote: >> >> >>> On Oct 17, 2016, at 9:57 AM, Michael Gottesman >> <mailto:mgotte

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

> On Oct 17, 2016, at 12:01 PM, Michael Gottesman wrote: > > >> On Oct 17, 2016, at 11:53 AM, Michael Gottesman via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >>> On Oct 17, 2016, at 10:00 AM, Joe Groff >> <mailto:jgr...@a

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

> On Oct 17, 2016, at 10:19 AM, Joe Groff wrote: > > >> On Oct 17, 2016, at 9:57 AM, Michael Gottesman wrote: >> >>> >>> On Oct 17, 2016, at 9:42 AM, Joe Groff via swift-dev >>> wrote: >>> >>> On Oct 16, 2016, at 1:10 PM, Dave Abrahams via swift-dev wrote: on

Re: [swift-dev] TWISt-shout Newsletter 2016-10-17

Suggestion: @swift-ci is not an interesting contributor in terms of contributor counts. You may want to filter that out of your counts to make that data more meaningful. Michael > On Oct 17, 2016, at 10:35 AM, Kenny Leung via swift-dev > wrote: > > Here is your TWISt-shout Newsletter for the

Re: [swift-dev] TWISt-shout Newsletter 2016-10-17

You don't need to do that. Swift-CI only should be on merge commits (which you should arguably be ignoring anyways). I think this is what you want: git log --format='%an' --no-merges --since '-1 week' | sort | uniq -c Michael > On Oct 17, 2016, at 12:22 PM, Kenny Leung wrote: > > Hi Michael.

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

> On Oct 17, 2016, at 12:40 PM, John McCall wrote: > >> On Oct 17, 2016, at 10:19 AM, Joe Groff via swift-dev >> wrote: >>> On Oct 17, 2016, at 9:57 AM, Michael Gottesman wrote: >>> On Oct 17, 2016, at 9:42 AM, Joe Groff via swift-dev wrote: > On Oct 16, 201

Re: [swift-dev] TWISt-shout Newsletter 2016-10-17

; ). Michael > On Oct 17, 2016, at 1:20 PM, Kenny Leung wrote: > > Yep. Works great. Thanks! > > * swift:156 - Michael Gottesman (21), Doug Gregor (17), Graydon Hoare (15) > > This must have been your ploy all along :-) > > -Kenny > > >> On Oct 17, 2016, at 12:26 PM, Michael Gottesman wro

Re: [swift-dev] smoke test not very smoky?

> On Oct 18, 2016, at 6:40 PM, Dave Abrahams via swift-dev > wrote: > > > I thought the smoke test was supposed to be a fairly quick test > that just covered the basics, but it seems to be doing plenty of *really > long* tests, for example: > https://ci.swift.org/job/swift-PR-Linux-smoke-test/

[swift-dev] PR Tests Failing

My PR test is failing due to something unrelated: https://ci.swift.org/job/swift-PR-osx-smoke-test/2441/console Does anyone know what is going on? Michael ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev

Re: [swift-dev] PR Tests Failing

I just talked with Roman. He said that this was due to his commit earlier and that we need to do clean builds to work around it. Perhaps we should clean the workspaces? Michael > On Oct 19, 2016, at 2:39 PM, Michael Gottesman via swift-dev > wrote: > > My PR test is failing due

[swift-dev] PRs not triggering with @swift-ci

I have been trying to trigger pull request testing for a little bit and nothing seems to be happening. Is anyone else running into this? This is the PR: https://github.com/apple/swift/pull/5396 ___ swift-dev mailing list swift-dev@swift.org https://list

Re: [swift-dev] PRs not triggering with @swift-ci

n though I find that to be unlikely). Also when I look online, I see that the news reports are saying that the issue has been resolved. Mishal/Doug, do you have any insight into this? > > On 21 Oct 2016, at 12:12, Michael Gottesman via swift-dev wrote: > >> I have been trying to tr

Re: [swift-dev] PRs not triggering with @swift-ci

rts are saying that the issue >> has been resolved. >> >> Mishal/Doug, do you have any insight into this? >> >>> >>> On 21 Oct 2016, at 12:12, Michael Gottesman via swift-dev wrote: >>> >>>> I have been trying to trigger pull request test

Re: [swift-dev] Inability to leverage privacy in the stdlib

> On Oct 23, 2016, at 3:30 PM, Alexis Beingessner via swift-dev > wrote: > > Dave pointed out to me this week that the build crashes if the stdlib tries > to use private/fileprivate. I tried it myself and lo and behold the linker > can't find the private symbols. He couldn't recall what about

Re: [swift-dev] Purpose of validation-test/Reflection/reflect_*.swift

> On Oct 26, 2016, at 5:29 PM, Alexis via swift-dev wrote: > > I’m not clear on what the reflection tests are attempting to actually verify. > Just that we don’t change the internal layout of these types accidentally? > We’re churning up the layouts of a lot of the collections to get things al

Re: [swift-dev] Stack dump of the compiler?

Are you talking about the prettyprint stack dump? I think that may have gone away after the recent update to the newer llvm/clang. I think there is a bug to look into what happened here, but no one has had the time to look into it. Michael > On Oct 26, 2016, at 8:53 PM, rintaro ishizaki via sw

Re: [swift-dev] Performance degradation with 3.0.1(String comparison)

> On Nov 3, 2016, at 11:07 PM, Pushkar N Kulkarni via swift-dev > wrote: > > Hello, > > A colleague of mine who's doing performance testing with some server-side > Swift frameworks like Kitura, Perfect and Zewo found a 15-20% degradation > with a simple "Hello World" benchmark, with the 3.0.

Re: [swift-dev] Casting shadow protocols

> On Nov 7, 2016, at 11:23 AM, Alexis via swift-dev wrote: > > >> On Nov 4, 2016, at 11:55 PM, Dave Abrahams via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >> on Fri Nov 04 2016, Slava Pestov > > wrote: >> >>> If the casts are always in one direct

Re: [swift-dev] High-level SIL Optimization: How do I get a FuncRef from the stdlib?

> On Nov 15, 2016, at 9:02 PM, Ben Ng wrote: > > Hi Michael, > > No, I did not. I don't see swift-dev in the cc line of your email... this > might be an issue with the Inbox for iOS client that I'm using. Ok! This happens sometimes (hit reply instead of reply-all or the like). +CC swift-dev

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

Question. How did this get through PR testing? Sent from my iPhone > On Nov 16, 2016, at 6:01 AM, Ankit Aggarwal via swift-dev > wrote: > > This is mine, checking. > >> On 16-Nov-2016, at 6:12 PM, no-re...@swift.org wrote: >> >> [FAILURE] oss-swift-incremental-RA-linux-ubuntu-16_10 [#519] >>

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

SGTM! Thanks! > On Nov 16, 2016, at 12:02 PM, ankit_aggar...@apple.com wrote: > > I figured this was a 16.10 issue because PR bot (16.04) passed, however I > wasn't able to reproduce this locally after installing 16.10, I pushed a > commit to pin point the failure line but that integration wen

Re: [swift-dev] High-level SIL Optimization: How do I get a FuncRef from the stdlib?

+CC Slava. He has been messing around with this area in the past bit since many of us have looked at this. He is the person you want. Michael > On Nov 25, 2016, at 8:42 PM, Ben Ng wrote: > > Hi everyone, > > I’ve made good progress with the information in this thread but I can’t > figure ou

Re: [swift-dev] Questions about ARC

> On Nov 30, 2016, at 6:25 PM, Jiho Choi via swift-dev > wrote: > > Thanks for clarifications. I have a couple of follow-up questions. > > 1. Could you please provide more information (e.g. source code location) > about the optimization applying non-atomic referenc

[swift-dev] Proposal: SILValue SSA Instructions

Hello everyone! This is a proposal for 2 instructions needed to express borrowing via SSA at the SIL level. The need for these were discovered while I was prototyping a SIL ownership verifier. A html version of the proposal: https://gottesmm.github.io/proposals/sil-ownership-value-ssa-operatio

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

> 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 >>> wrote: >>> >>> Hello everyone! >>&g

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

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 and inline below. Michael # Summary Thi

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

le.com>> wrote: >>>> On Dec 6, 2016, at 11:29 AM, John McCall >>> <mailto:rjmcc...@apple.com>> wrote: >>>> >>>>> On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev >>>> <mailto:swift-dev@swift.org>> wrote: &g

Re: [swift-dev] proposed change for master-next merges

> On Dec 8, 2016, at 7:43 AM, Saleem Abdulrasool via swift-dev > wrote: > > Having been involved in the update process for the next branches, I'm really > excited to see this type of change. > > I think that the "simple" approach is both better to work and collaborate in > as well as closer

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

Sent from my iPhone > On Dec 8, 2016, at 9:59 PM, Bob Wilson wrote: > > Yes, he renamed sil-extract to sil-func-extractor > (https://github.com/apple/swift/pull/6155/files) and missed updating some > places. This should fix it: https://github.com/apple/swift/pull/6159 > > (FWIW, I much pref

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

gt;>> On Dec 6, 2016, at 11:29 AM, John McCall >> <mailto:rjmcc...@apple.com>> wrote: >>> >>>> On Dec 6, 2016, at 10:17 AM, Joe Groff via swift-dev >>> <mailto:swift-dev@swift.org>> wrote: >>>>> On Dec 5, 2016, at 4:24 PM,

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

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

[swift-dev] Announcing bug-reducer

Hey everyone. Many of us from LLVM land are familiar with the tool called bugpoint. For a long time, we have wanted this in SIL, but no one has gotten around to doing it... until now! (What can I say I have tooling problems = p). The tool called 'bug-reducer' is not a full bugpoint tool, but ha

Re: [swift-dev] Namespacing Compiler-Stdlib Interfaces

One thing to be careful with here is that sometimes SIL test cases say that are the stdlib but only implement the functionality that they will use (taking advantage of how I believe currently these are checked lazily). If I am correct (which my memory may not be), we will need a flag to be less

Re: [swift-dev] Performance issues in automatic reference counting (ARC)?

> On Dec 17, 2016, at 11:13 AM, Brian Gesiak via swift-dev > wrote: > > Hello all! > > I really enjoyed Chris Lattner's slides from his talk at IBM >

  1   2   >