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 m

[swift-dev] Combining Skin Tone Emoji Into Single Extended Grapheme Clusters

Hello, I would like to fix rdar://20511834 , which is that the new skin tone and multi-person grouping emoji introduced with iOS 8.3 and OS X 10.10.3 are represented as multiple extended grapheme clusters by Swift.String, and I have a few questions. 1. Is this something we want to fix at this tim

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

> On Dec 17, 2015, at 1:08 PM, Chris Lattner wrote: > >> >> 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-evolutio

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

Sent from my moss-covered three-handled family gradunza > On Dec 17, 2015, at 4:52 PM, Jordan Rose via swift-dev > wrote: > > >>> On Dec 17, 2015, at 14:48, Joe Groff via swift-dev >>> wrote: >>> >>> >>> On Dec 17, 2015, at 2:34 PM, Erik Eckstein via swift-dev >>> wrote: >>> >>> Hi, >

[swift-dev] StdlibUnittest and Debug compilers

Hi, all. I filed SR-292 today complaining about StdlibUnittest taking 13 minutes to build on my machine, 9 of which are spent in SIL optimization. I had a pretty strong feeling that this happened some time in the last few months. Continuing to experiment,

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

> On Dec 17, 2015, at 14:48, 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: >>

Re: [swift-dev] tips for debugging the swift executable

Better yet, since LLDB is where we have comprehensive support for debugging Swift binaries you'll have a common debugger experience across your C/C++/Swift code. Kate Stone k8st...@apple.com  Xcode Low Level Tools > On Dec 17, 2015, at 3:09 PM, Joe Groff via swift-dev > wrote: > > >> On De

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

Re: [swift-dev] The Swift Programming Language Translations

This sounds like a good idea, especially for the second benefit. I’m just gonna keep translating text for now, but I'll have to think of a solution for that later. Something else: I’ve been translating most parts of the code, such as variable and function names. The resulting code is a bit weir

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

> 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 on arm64. Not true on armv7; the GPR parameters are r0-r3 but GPR > return is r

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 3:34 PM, Joe Groff via swift-dev > wrote: > > On ARMv7 and ARM64, the argument and return register sets are the same Nit: True on arm64. Not true on armv7; the GPR parameters are r0-r3 but GPR return is r0-r1. -- Greg Parker gpar...@apple.com Runtime Wrangler

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

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 want to codify that in the stable ABI. Values of these types are likel

Re: [swift-dev] tips for debugging the swift executable

> On Dec 17, 2015, at 2:57 PM, Rafkind, Jon via swift-dev > wrote: > > I use gdb on linux to debug the swift binary. I find that gdb takes about 20 > seconds just to read the symbols before I can even interact with gdb. I was > wondering if anyone knew of a way to decrease the symbol load tim

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

[swift-dev] tips for debugging the swift executable

I use gdb on linux to debug the swift binary. I find that gdb takes about 20 seconds just to read the symbols before I can even interact with gdb. I was wondering if anyone knew of a way to decrease the symbol load time, either by some gdb settings or by compiling swift/llvm/clang in such a way

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

> On Dec 17, 2015, at 2:34 PM, Erik Eckstein via swift-dev > wrote: > > Hi, > > I'm currently working on improving alias analysis in the optimizer and I run > into following problem: > > If alias analysis assumes that inout may not alias any other object, we may > violate memory safety. Not

[swift-dev] inout and aliasing in the optimizer

Hi, I'm currently working on improving alias analysis in the optimizer and I run into following problem: If alias analysis assumes that inout may not alias any other object, we may violate memory safety. Note that currently it's not always assumed, e.g. not in computeMemoryBehavior for apply i

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

> On Dec 17, 2015, at 5:37 AM, Emanuel Zephir wrote: > > Okay, that works. > > I have a few questions about SR-210: > > 1) The attached patch adds support for undefined integer value-cases in the > switch_value instruction. What is the runtime meaning of this construct? > > 2) Are there any

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

> On Dec 17, 2015, at 3:37 AM, Emanuel Zephir via swift-dev > wrote: > > Okay, that works. > > I have a few questions about SR-210: > > 1) The attached patch adds support for undefined integer value-cases in the > switch_value instruction. What is the runtime meaning of this construct? SIL

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] operator overloads

Ok I will. I just wanted to make sure it was buggy behavior before filing. On 12/17/2015 11:24 AM, Dmitri Gribenko wrote: On Thu, Dec 17, 2015 at 11:20 AM, Rafkind, Jon via swift-dev wrote: How does the Swift compiler determine which method or operator to call given

Re: [swift-dev] operator overloads

On Thu, Dec 17, 2015 at 11:20 AM, Rafkind, Jon via swift-dev wrote: > How does the Swift compiler determine which method or operator to call given > a set of overloads at a given call site? This question may conflate two > issues: method overloads and operator overloads, but it seems at least >

[swift-dev] operator overloads

How does the Swift compiler determine which method or operator to call given a set of overloads at a given call site? This question may conflate two issues: method overloads and operator overloads, but it seems at least superficially that they are related. Somehow they end up using different rul

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] Starter project: SR-2: Build configuration directives can not wrap switch cases

On Thu, Dec 17, 2015 at 12:08 PM, Chris Lattner wrote: > On Dec 17, 2015, at 9:06 AM, Dmitri Gribenko via swift-dev < > swift-dev@swift.org> wrote: > >> Quick question about this one. > >> > >> As mentioned in SR-2, the current grammar for switch > >> statements [1] does not allow for compiler co

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] 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? I think it makes sense to bring it up on swift-evolution. I tend to agree with your ar

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

On Thu, Dec 17, 2015 at 7:58 AM, Meador Inge wrote: > On Sun, Dec 6, 2015 at 5:04 PM, Dmitri Gribenko via swift-dev > wrote: > >> Hi, >> >> If you're looking for a starter project in the frontend area (parser >> in this case), here is one. >> >> https://bugs.swift.org/browse/SR-2 >> >> This code

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

On Sun, Dec 6, 2015 at 5:04 PM, Dmitri Gribenko via swift-dev < swift-dev@swift.org> wrote: Hi, > > If you're looking for a starter project in the frontend area (parser > in this case), here is one. > > https://bugs.swift.org/browse/SR-2 > > This code should be accepted, but it is rejected now: >

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

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? > On Dec 15, 2015, at 7:15 PM, Jesse Rusak wrote: > >>> On Dec 14, 2015, at 9:42 PM, Chris Lattner via swift-dev >>> mailto:swift-dev@swift.org>> wrote: > >>> T

[swift-dev] Putting Swift Programming Language Book under Git version control

I just saw Chris Lattners tweet about the translation section of the Swift Documentation page . The idea to encourage community driven translations into other languages is great. But getting multiple people to collaborate on a single translation language requi

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

Okay, that works. I have a few questions about SR-210: 1) The attached patch adds support for undefined integer value-cases in the switch_value instruction. What is the runtime meaning of this construct? 2) Are there any other SIL instructions in the select/switch family that need modifications?