Re: [swift-dev] Starter project: Remove old mirrors

> On Dec 6, 2015, at 2:20 AM, Dmitri Gribenko via swift-dev > wrote: > > We need new runtime entry points that make sense for the new mirror > implementation. The current entry points (the _reflect() function and > all its implementation details) directly depend on the old mirrors. > This step

Re: [swift-dev] Trying to work out how default parameters work

> On Dec 8, 2015, at 2:43 AM, Brent Royal-Gordon via swift-dev > wrote: > > My first question is simply this: is this the best place for the sort of > question I’m about to ask? Is there an IRC channel or Slack or something > where people who are working with Swift’s compiler internals are ha

Re: [swift-dev] Questions about _Reflectable and CustomReflectable

> On Dec 8, 2015, at 11:44 AM, Austin Zheng via swift-dev > wrote: > > Hello devs, > > I have two questions about the _Reflectable and CustomReflectable protocols > in the stdlib. (These are both in context of Jira ticket SR-88.) > > First, I notice that _Reflectable encompasses both CustomR

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

> On Dec 9, 2015, at 10:05 AM, Nick Wellnhofer via swift-dev > wrote: > > On 09/12/2015 18:55, Nick Wellnhofer via swift-dev wrote: >>> Is there a better way to get that symbol, and why wasn’t this a problem for >>> x86_64? >> >> AFAICS, this is a problem for x86_64 Linux. It's not a problem o

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

> On Dec 8, 2015, at 8:57 PM, Chris Lattner via swift-dev > wrote: > > 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 spec

Re: [swift-dev] Initialization of default values

> On Dec 9, 2015, at 3:28 PM, Matthew Johnson via swift-dev > wrote: > > I am working on a proposal for flexible memberwise initialization and would > like to understand how Swift currently handles initialization of members that > have a default specified in the declaration when an initialize

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

> 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 the > textual SIL language. In memory, the debug information attached

Re: [swift-dev] [SR-40] Port Swift to Arm progress / question

> On Dec 10, 2015, at 9:29 AM, William Dillon wrote: > > Yep. I see that are a few of those in there (1700 and change). When it > comes to linking and ELF, I am fumbling in the dark a bit. With the hope of > getting some context, I decided to see whether R_ARM_REL32 is used in any > other

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

> On Dec 11, 2015, at 7:13 AM, Douglas Gregor via swift-dev > wrote: > > >> On Dec 11, 2015, at 4:33 AM, Geordie Jay via swift-dev >> wrote: >> >> Hi, maybe one of the Apple devs can help out with this quick Q: >> >> To interface with the JNI, we’d presumably need to call swift functions f

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 vi

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

> On Dec 15, 2015, at 2:34 PM, Adrian Prantl wrote: > >> >> On Dec 15, 2015, at 2:27 PM, Joe Groff wrote: >> >>> >>> On Dec 15, 2015, at 1:25 PM, Adrian Prantl wrote: >>> >>>> >>>> On Dec 10, 2015, at 10:19 AM,

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

> On Dec 15, 2015, at 8:12 AM, Ryan Lovelett via swift-dev > wrote: > > I've been playing around with a Swift wrapper for the FFmpeg C libraries > (e.g., libavutil, libavcodec, libavformat, etc...). While providing some > extensions to some of the core C structures I've run into something that

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

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

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

> On Dec 16, 2015, at 11:24 AM, Kevin Ballard via swift-dev > wrote: > > On Wed, Dec 16, 2015, at 12:12 AM, Dave Abrahams wrote: >> >>> Come to think of it, what's the actual use-case for withUnsafePointer()? >> >> I'm not sure we still have one that isn't covered by &x; that's my point. >>

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

> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev > wrote: > > On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote: >> >> Yeah, it seems to me like a reasonable refinement for 'withUnsafePointer' to >> take an immutable parameter

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

> On Dec 15, 2015, at 6:39 PM, Dave Abrahams via swift-dev > wrote: > > >> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev >> wrote: >> >> On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote: >>> >>>

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

e: >>>> >>>>> On Dec 15, 2015, at 6:46 PM, Kevin Ballard wrote: >>>>> >>>>> On Tue, Dec 15, 2015, at 06:39 PM, Dave Abrahams wrote: >>>>>> >>>>>>> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via sw

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

> On Dec 16, 2015, at 11:47 AM, Kevin Ballard wrote: > > On Wed, Dec 16, 2015, at 11:42 AM, Joe Groff wrote: >> >>> On Dec 16, 2015, at 11:24 AM, Kevin Ballard via swift-dev >>> wrote: >>> >>> On Wed, Dec 16, 2015, at 12:12 AM, Dave Abrahams wrote: > Come to think of it, what's the

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

> On Dec 16, 2015, at 11:59 AM, Kevin Ballard wrote: > > On Wed, Dec 16, 2015, at 11:49 AM, Joe Groff wrote: >> >>> On Dec 16, 2015, at 11:47 AM, Kevin Ballard >> > wrote: >>> >>> On Wed, Dec 16, 2015, at 11:42 AM, Joe Groff wrote: > On Dec 16, 2015, at 11:24

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

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

[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] 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 pa

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

> 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 small trivial types l

Re: [swift-dev] [swift-users] Cross Compiling Swift for Bare Metal?

> On Dec 19, 2015, at 6:53 PM, Chaitanya Mannem via swift-users > wrote: > > Hi, > > > I wanted to know if it is possible to compile swift code for bare metal. I > know there is a runtime but does swift depend on it to execute even if I > don't use those features?, can I disable them someho

[swift-dev] swift_retainCount in CoreFoundation

It looks like the corelibs implementation of CoreFoundation references swift_retainCount in order to implement CFGetRetainCount. Is getting the retain count necessary to CF functionality, or can these functions be removed? -Joe ___ swift-dev mailing li

Re: [swift-dev] swift_retainCount in CoreFoundation

> On Dec 22, 2015, at 1:08 PM, Joe Groff via swift-dev > wrote: > > It looks like the corelibs implementation of CoreFoundation references > swift_retainCount in order to implement CFGetRetainCount. Is getting the > retain count necessary to CF functionality, or can

[swift-dev] Combining native and ObjC swift_class_getInstanceExtents entry points

In the runtime currently, there are two entry points for asking for the size of a class's instances, one for known-native Swift classes, and one for possibly-ObjC classes. It looks like they're only currently used for _debugPrecondition checks in ManagedBuffer's initializers to catch improperly

Re: [swift-dev] swift_retainCount in CoreFoundation

> On Dec 25, 2015, at 9:02 PM, Philippe Hausler wrote: > > > On Dec 22, 2015, at 1:08 PM, Joe Groff via swift-dev > swift.org <https://lists.swift.org/mailman/listinfo/swift-dev>> wrote: > > > > It looks like the corelibs implementation of CoreFoundation

Re: [swift-dev] swift_retainCount in CoreFoundation

> On Dec 26, 2015, at 12:52 PM, Philippe Hausler wrote: > > >> On Dec 26, 2015, at 12:31 PM, Joe Groff > <mailto:jgr...@apple.com>> wrote: >> >>> >>> On Dec 25, 2015, at 9:02 PM, Philippe Hausler >> <mailto:phaus...@apple.com>

Re: [swift-dev] Distinguishing classes from value types/ObjC bridged types?

> On Dec 29, 2015, at 4:50 PM, Austin Zheng via swift-dev > wrote: > > Hello, > > First, some background. I'm currently working on refactoring the way mirrors > are handled within the Swift standard library (conversion from use of > _Reflectable and _MirrorType to CustomReflectable). > > No

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

> On Dec 29, 2015, at 9:04 PM, Luke Howard via swift-dev > wrote: > > I’m seeing an assertion failure when I try to compile the following on Linux: > > typealias TypeMetadataAccessor = @convention(c) () -> AnyClass? > > The assertion failing is: > >assert(getASTContext().LangOpts.E

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

> On Dec 30, 2015, at 10:05 AM, Philippe Hausler wrote: > > That is the asset in the compiler that is being hit when the code > unsafeBitCasts to a c function. > > typealias TypeMetadataAccessor = @convention(c) () -> AnyClass? > let accessor = unsafeBitCast(symbol, TypeMetadataAccessor.self)

Re: [swift-dev] ExistentialMetatypeType assertion failure on Linux

> On Dec 30, 2015, at 2:41 PM, Luke Howard wrote: > > >>> It looks like you're trying to poke at private runtime metadata structures; >>> please don't do that. What are you trying to do? >> >> Per our exchange yesterday – implement NSStringFromClass() heuristics for >> NSKeyedArchiver > > S

Re: [swift-dev] Linker script on Linux

> On Dec 30, 2015, at 1:24 AM, Luke Howard via swift-dev > wrote: > > Per [SR-404], anything that consumed libFoundation could not dynamically cast > to a Foundation protocol because the build script was missing the magic > swift.ld linker script to advertise the start of the protocol conform

Re: [swift-dev] Where are @_attributes documented?

> On Dec 30, 2015, at 4:58 PM, Ling Wang via swift-dev > wrote: > > I want to submit some patches but I’m not sure whether I should apply some > @_attributes(like @_transparent and @_semantics) that I see in stdlib to my > API because I don’t know their meanings. If it starts with an undersc

Re: [swift-dev] Compiling SIL with swiftc

> On Dec 31, 2015, at 2:33 AM, Luke Howard via swift-dev > wrote: > > Newbie question, is the following supposed to work? > > $ ./swiftc -emit-sil -o lookup.sil lookup.swift > $ ./swiftc -parse-sil -o lookup lookup.sil > > It fails with a gazillion errors: > > lookup.sil:61:25: error: use of

Re: [swift-dev] Where are @_attributes documented?

> On Dec 30, 2015, at 7:42 PM, Ling Wang wrote: > > Yes I’m submitting patches to stdlib. Thanks for pointing me to the doc > folder. Even if you're working on the stdlib, I wouldn't worry too much about using any internal attributes right away. The performance team usually handles adding th

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

> On Dec 31, 2015, at 11:47 AM, Keith Smiley via swift-dev > wrote: > > Would it be worthwhile for the swift team if those of us who have created > many swift related radars to copy them over to bugs.swift.org > ? Definitely. If you can spare the extra effort, we'd ap

Re: [swift-dev] swift_retainCount in CoreFoundation

> On Jan 4, 2016, at 12:10 PM, Tony Parker wrote: > > Hi Joe, > > I think we can probably elide CFGetRetainCount from the corelibs-foundation. > It’s almost always an anti-pattern to check a retain count anyway (as I’m > sure you’re aware since you’re trying to kill the swift version of it).

Re: [swift-dev] C Macros and Variadic functions

> On Jan 5, 2016, at 1:57 PM, Kate Stone via swift-dev > wrote: > >> On Jan 5, 2016, at 12:32 PM, Ryan Lovelett via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> Just to be clear though the intent of my question was not to quibble >> with compiler error messages. My real question is

Re: [swift-dev] Understanding runtime entry points

> On Jan 1, 2016, at 10:58 PM, Austin Zheng via swift-dev > wrote: > > Hello, > > I'm trying to better understand how calls are made between the Swift standard > library code and the runtime entry points. I've read through most of the > documentation in the repo but still have some questions

Re: [swift-dev] Understanding runtime entry points

> On Jan 6, 2016, at 12:46 PM, Austin Zheng wrote: > > Thanks Joe, this is incredibly helpful, especially the note about how enums > are passed in 'piecewise'. To clarify, what you're seeing in EnumMirror is not the enum itself, but the _EnumMirror structure, which is itself designed to be bi

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

This sounds awesome. Should we still consider using a non-pointer isa representation on 64 bit platforms? 16 bytes per object header is still kinda big. If we laid out the np-isa bits so that the "side allocation" bit were the MSB, and the strong refcount immediately below it, we could pull the

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

> On Mar 16, 2016, at 4:08 PM, Greg Parker wrote: > > >> On Mar 16, 2016, at 9:25 AM, Joe Groff wrote: >> >> This sounds awesome. Should we still consider using a non-pointer isa >> representation on 64 bit platforms? 16 bytes per object header is still >> kinda big. If we laid out the np-i

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

> On Mar 22, 2016, at 5:57 AM, Bryan Chan via swift-dev > wrote: > > I tried to google for an answer but couldn't find anything. What is the > correct way to do the following on Linux? > > @_silgen_name("foo") > func foo(theInt: UInt) > -> (a: UInt, b: UInt, c: UInt) > > var (d, e, f) = foo(

Re: [swift-dev] Build Error: Relocation R_X86_64_PC32

> On Mar 22, 2016, at 9:55 AM, Ryan Lovelett wrote: > > On Mon, Mar 14, 2016, at 06:42 PM, Dmitri Gribenko wrote: >> On Mon, Mar 14, 2016 at 3:38 PM, Ryan Lovelett >> wrote: >>> On Tue, Mar 1, 2016, at 12:16 AM, Dmitri Gribenko wrote: IIRC there is no issue in the bug tracker, please feel

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

> On Mar 22, 2016, at 11:30 AM, Bryan Chan wrote: > > jgr...@apple.com wrote on 2016-03-22 12:05:06 PM: > > > On Mar 22, 2016, at 5:57 AM, Bryan Chan via swift-dev > wrote: > > > > > I tried to google for an answer but couldn't find anything. What is > > > the correct way to do the following o

Re: [swift-dev] large dictionary literal overflows swiftc stack

I'd recommend testing to see if this is improved in Swift 3, if it's practical to switch your codebase over. There are some type checker improvements there that didn't make it into Swift 2. -Joe > On Mar 22, 2016, at 12:13 PM, Rafkind, Jon via swift-dev > wrote: > > Attached is a file from a

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

> 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 > > them Swift-like calling conventions. Many of them also have > > important semantics that the compiler needs to be

Re: [swift-dev] large dictionary literal overflows swiftc stack

> On Mar 22, 2016, at 1:41 PM, Rafkind, Jon wrote: > > Ok I will test with swift 3, but just to avoid any confusion I am not a > developer on PerfectLib. I was just using that file as a test case for my > application that is based on the swiftc code base. My application is designed > to consu

Re: [swift-dev] long double usage in swift

> On Mar 23, 2016, at 2:25 PM, Saleem Abdulrasool via swift-dev > wrote: > > Hi, > > I was looking at an ABI related issue on Windows. In trying to construct a > test case, it seems that I am unable to import a declaration using a long > double into swift. I was wondering if there is somet

[swift-dev] Requiring Xcode 7.3 to build Swift master for Apple platforms?

Xcode 7.3 included a fix for the Apple linker that's necessary to support some of the metadata format changes we're making in Swift 3. I have some workarounds in place that I'd like to remove since they suppress linker coalescing of some constant strings. Would anyone object to us requiring usin

Re: [swift-dev] Requiring Xcode 7.3 to build Swift master for Apple platforms?

>> It contributes to the message of openness. >> >> -Dave >> >> Enviado desde mi iPhone >> >>> El mar 29, 2016, a las 2:02 PM, Joe Groff via swift-dev >>> escribió: >>> >>> Xcode 7.3 included a fix for the Apple linker

Re: [swift-dev] ObjC Interoperability under armv7--linux-gnueabi

> On Mar 29, 2016, at 1:03 PM, Iliya Trub via swift-dev > wrote: > > Dear colleagues > Ihave built swiftc, libswiftCore.so and other outputs under > armv7--linux-gnueabi with open source ObjC-runtime and enabled ObjC interop. > I linked the simplest swift-application, which creates the instan

Re: [swift-dev] ObjC Interoperability under armv7--linux-gnueabi

> On Mar 30, 2016, at 3:27 AM, Iliya Trub wrote: > > I'd like to add, that I have overcomed "subject"error in very simple path. I > indeed forgot to add -fobjc-runtime=gnustep to all needed places. THIS error > disappeared, but the new error appeared: > > main2: dwarf/Gparser.c:456: fetch_pro

Re: [swift-dev] isUniquelyReferenced issues

> On Mar 31, 2016, at 3:58 PM, Patrick Pijnappel via swift-dev > wrote: > > In trying to implement a COW type, but I'm running into problems with > isUniqueReferenced breaking in even fairly simple cases. For example (with > -O) the code below prints "bar: false", commenting out the print in

Re: [swift-dev] isUniquelyReferenced issues

> On Mar 31, 2016, at 4:21 PM, Joe Groff via swift-dev > wrote: > >> >> On Mar 31, 2016, at 3:58 PM, Patrick Pijnappel via swift-dev >> wrote: >> >> In trying to implement a COW type, but I'm running into problems with >> isUniqueRe

Re: [swift-dev] isUniquelyReferenced issues

> On Mar 31, 2016, at 11:49 PM, Patrick Pijnappel > wrote: > > The modified version doesn't seem to change any of the results (on -O or > -Onone). Note that the problem is that it's not uniquely referenced inside > bar where it actually should be – that would mean that ownership is currently

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

> On Apr 6, 2016, at 10:21 AM, Saleem Abdulrasool via swift-dev > wrote: > > Hi, > > I was playing around with the idea of swift and Windows since there are some > interesting differences between COFF/PE and (ELF and MachO). > > PE/COFF does not directly address symbols in external modules

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

> 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 this is to say that > argument labels are a part of the name, and therefore two declarati

Re: [swift-dev] Help needed: SE-0035 design detail

> On Apr 10, 2016, at 12:46 PM, Daniel Duan via swift-dev > wrote: > > Hi all, > > I'm in the process of implementing SE-0035, which limits capturing inout > parameter to @noescape contexts. The proposal is clear on capture behavior for > the following: > > 1. closure literals > 2. nested fun

Re: [swift-dev] Help needed: SE-0035 design detail

> On Apr 11, 2016, at 1:28 PM, Daniel Duan via swift-dev > wrote: > >> Joe Groff via swift-dev swift.org> writes: >> >> return local // returning forms a closure, so ref is escapable > > My plan was to check all return statements with FuncDecl as

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

> On Apr 11, 2016, at 8:40 AM, John McCall wrote: > >> 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-rea

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

> On Apr 11, 2016, at 3:19 PM, Saleem Abdulrasool via swift-dev > wrote: > > On Thu, Apr 7, 2016 at 2:12 PM, Saleem Abdulrasool > wrote: > On Wed, Apr 6, 2016 at 10:21 AM, Saleem Abdulrasool > wrote: > Hi, > > I was playing around with the idea of swift and Windows since there are some >

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

> 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 > > but sadly the packages I’ve found haven’t been

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

> 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 CLong type not Int. > > It changes what 'long' gets imp

[swift-dev] ObjC generic containers and ObjectiveCBridgeable conformance

Importing ObjC generics is currently disabled for the bridged container classes, NSArray, NSDictionary, and NSSet. To enable generics for these types, we need to figure out what to do about their interaction with ObjectiveCBridgeable container bridging. The mapping from generic Swift value type

Re: [swift-dev] Help with SR-1052: Handling generic return values

> On May 3, 2016, at 6:28 PM, Trent Nadeau via swift-dev > wrote: > > Can anyone help me with this? I replied to the patch: https://github.com/tanadeau/swift/commit/c1b3c8ed688b2bf231a8a0653ebbacd838549d5e#commitcomment-17347334 -Joe ___ swift-dev

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

> On May 5, 2016, at 4:18 PM, Sangjin Han via swift-dev > wrote: > > Hi, > > I made an experimental MSVC port. Of cause, dllimport/dllexport and the > driver for linking and many other part is not implemented. But dynamic > linking was possible with some trick. > > I think it is useful for

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

ectly the function in the DLL without import > library. > > The feature also needed when we link to static library. > > I don't know about the SIL, IR, so it is thankful someone tell me how to > approach this problem. > > 2016-05-07 5:01 GMT+09:00 Saleem Abdulr

Re: [swift-dev] Consider removing the space in Swift AST dump's "decl" attribute?

> On May 9, 2016, at 10:00 AM, Minsheng Liu via swift-dev > wrote: > > Thanks for your information. However, what I intend to work on is a > Swift-to-JS translator, which I guess probably need to stick with the > upstream anyway. I think that make the output a bit more parsing-friendly > wil

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

> swift -O Hello.swift > LLVM ERROR: Program used external function > '__imp__swift_getExistentialTypeMetadata' which could not be resolved! > > It seems swift.exe call directly the function in the DLL without import > library. > > The feature also ne

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

> On May 10, 2016, at 2:25 PM, Saleem Abdulrasool wrote: > > On Monday, May 9, 2016, Joe Groff wrote: > > > On May 9, 2016, at 7:19 PM, Saleem Abdulrasool > > wrote: > > > > On Sat, May 7, 2016 at 7:55 PM, Sangjin Han wrote: > > One more, > > > > I couldn't build the libswiftCore.dll which

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

> > > swift -O Hello.swift > > LLVM ERROR: Program used external function > > '__imp__swift_getExistentialTypeMetadata' which could not be resolved! > > > > It seems swift.exe call directly the function in the DLL without import > > library. > &

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

> On May 11, 2016, at 10:18 PM, Chris Lattner via swift-dev > wrote: > > 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 implem

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

> On May 12, 2016, at 9:27 AM, Jordan Rose via swift-dev > wrote: > > > - I’m uncomfortable with using the term “undefined behavior” as if it’s > universally understood. Up until now we haven't formally had that notion in > Swift, just “type safety” and “memory safety” and “invariant-preserv

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

> 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-dev wrote: - I’m uncomfortable wi

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

> On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev > 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 _Contigu

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

Looks like my fault. I'll look into fixing it. -Joe > On May 18, 2016, at 3:58 PM, no-re...@swift.org wrote: > > New issue found! > > [FAILURE] oss-swift-incremental-RA-osx [#4118] > > Build URL:https://ci.swift.org/job/oss-swift-incremental-RA-osx/4118/ > Project: oss-swift-increment

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

Should be fixed by e248f83df9afc7bd588f264984f6ca0396c8015d. -Joe > On May 18, 2016, at 4:00 PM, Joe Groff via swift-dev > wrote: > > Looks like my fault. I'll look into fixing it. > > -Joe > >> On May 18, 2016, at 3:58 PM, no-re...@swift.org wrote: >>

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

> On May 19, 2016, at 9:07 AM, John McCall via swift-dev > wrote: > >> 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. >> >

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

> On May 18, 2016, at 6:01 PM, Saleem Abdulrasool wrote: > > On Wednesday, May 18, 2016, Joe Groff wrote: > > > On May 18, 2016, at 1:51 PM, Saleem Abdulrasool via swift-dev > > wrote: > > > > Hi, > > > > It seems that there are assumptions about the ability to create relative > > address a

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

in a platform-independent way. -Joe > cheers, > Tom > > On Thu, May 19, 2016 at 9:51 AM Joe Groff via swift-dev > wrote: > > > On May 18, 2016, at 6:01 PM, Saleem Abdulrasool > > wrote: > > > > On Wednesday, May 18, 2016, Joe Groff wrote: > > >

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (swift-3.0-preview-1) #102

These failures should clear up once https://github.com/apple/swift/pull/2650 gets approved and merged. -Joe > On May 23, 2016, at 1:25 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-3.0-preview-1-incremental-RA-osx [#102] > > Build URL: > https://ci.swift.org/job/oss-swift-3.0-previ

Re: [swift-dev] Please remove your Swift build directory

> On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev > wrote: > > Hi, > > We have merged a CMake and build-script refactoring that requires a > from-scratch build. Trying to use an existing build directory will > result in strange errors in the middle of the build. > > Excuse me for

Re: [swift-dev] Please remove your Swift build directory

> On May 31, 2016, at 10:20 AM, Joe Groff via swift-dev > wrote: > > >> On May 31, 2016, at 9:37 AM, Dmitri Gribenko via swift-dev >> wrote: >> >> Hi, >> >> We have merged a CMake and build-script refactoring that requires a >>

Re: [swift-dev] NSProxy dynamic casting to Swift or ObjC class behaves differently

> On Jun 8, 2016, at 12:44 AM, Yavuz Nuzumlalı via swift-dev > wrote: > > Hi all, > > swift_dynamicCastClassUnconditional and > swift_dynamicCastObjCClassUnconditional methods behave differently while > verifying casting. > > swift_dynamicCastObjCClassUnconditional method calls -isKindOfCla

Re: [swift-dev] Help needed: Removing inout shadow copy from SILGen

> On Jun 8, 2016, at 7:38 PM, Daniel Duan via swift-dev > wrote: > > Hi all, > > I'm resuming work on removing the SILGen for the inout shadow copy. Making > this change involes quite a bit of tests updates. I'd love some one to review > this commit in SILGenProlog.cpp before I dive back into

Re: [swift-dev] Help needed: Removing inout shadow copy from SILGen

> On Jun 9, 2016, at 10:01 AM, Adrian Prantl wrote: > > On Jun 9, 2016, at 9:55 AM, Joe Groff wrote: >> >> >>> On Jun 8, 2016, at 7:38 PM, Daniel Duan via swift-dev >>> wrote: >>> >>> Hi all, >>> >>> I'm resuming work on removing the SILGen for the inout shadow copy. Making >>> this chang

Re: [swift-dev] Problem in parsing SIL

> On Jun 21, 2016, at 2:03 PM, Slava Pestov via swift-dev > wrote: > > Hi Mikio, > > Try this: > > swiftc -frontend -emit-silgen classdecl.swift > classdecl.sil > swiftc -parse-sil classdecl.sil > > I'm not sure why -emit-silgen sometimes emits type declarations and other > times not. The o

Re: [swift-dev] Requiring blocks (universally)

> On Jun 24, 2016, at 11:05 AM, Saleem Abdulrasool via swift-dev > wrote: > > Hi, > > The blocks runtime itself is pretty tiny, and works across various targets > already, so including it is not too onerous. As such, Id like to propose > enabling blocks across all the targets. > > This mak

Re: [swift-dev] SE-0095: SIL syntax and Any.self problem

> On Jul 4, 2016, at 9:29 AM, Josef Willsher via swift-dev > wrote: > > Hi everyone, > > I’ve been implementing SE-0095 (here) and have hit an issue around how > Any.self is treated. > > When in the type position, I parse Any like any other type, and resolve it to > be an empty protocol com

Re: [swift-dev] Fixits

> On Jul 7, 2016, at 10:19 AM, Erica Sadun via swift-dev > wrote: > > Where is the best place to request fixits? bugs.swift.org or on this list? > > I've been porting a lot of code to Swift 3 and finding a lot of issue and no > before you ask, I stupidly did not write them down as I went and

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

> 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 conversions from [String] to [NSString], String to NSString, > and

Re: [swift-dev] [Swift CI] Build Failure: 0. OSS - Swift Incremental RA - OS X (swift-3.0-preview-5) #8

Should be fixed by https://github.com/apple/swift/pull/3786. -Joe > On Jul 26, 2016, at 4:40 PM, no-re...@swift.org wrote: > > [FAILURE] oss-swift-3.0-preview-5-incremental-RA-osx [#8] > > Build URL: > https://ci.swift.org/job/oss-swift-3.0-preview-5-incremental-RA-osx/8/ > Project: os

Re: [swift-dev] Is developer snapshot 2016-07-29 broken?

> On Jul 31, 2016, at 5:12 AM, Charles Lane via swift-dev > wrote: > > I get a segmentation fault 11 at compile time with the 07/29 toolchain & > Xcode 8 beta 3. Can anyone point me in right direction to fix this? Should be addressed by https://github.com/apple/swift/pull/3918. -Joe > > Me

Re: [swift-dev] swift-corelibs-foundation failing in object conversion when building on Darwin host

> On Aug 4, 2016, at 1:21 PM, Philippe Hausler via swift-dev > wrote: > > With a freshly built toolchain from ToT swift, building ToT > swift-corelibs-foundation I am getting some very strange failures in the unit > tests: > > Test Suite 'TestNSKeyedArchiver' started at 13:15:01.843 > Test C

Re: [swift-dev] Swift's handling of function types

> On Aug 27, 2016, at 9:28 AM, Jens Persson via swift-dev > wrote: > > IMHO Swift's handling of function types violate the principle of least > surprise. > > In the example program below, are `a` and `b` really of the same function > type? > > I searched but couldn't find any proposal or di

  1   2   3   >