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

Now we have AnyHashable, NSUniqueObject in the archiver can go. I’ll file a PR. — Luke > On 11 Aug 2016, at 4:29 AM, Tony Parker via swift-dev > wrote: > > We have fixes ready to go for this keyed archiver issue but the inability to > get past CI has slowed us down on putting it in. > > - To

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

Would it be possible to separate the change to NSKeyedUnarchiver in 1d1ddba9 into a separate commit? > On 5 Aug 2016, at 6:21 AM, 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

Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

Or maybe not, looks like there’s a Unix transport in transports/unix.c. > On 10 May 2016, at 1:48 PM, Luke Howard via swift-dev > wrote: > > There is libxpc from NextBSD: > > https://github.com/NextBSD/libxpc <https://github.com/NextBSD/libxpc> > > You’d still

Re: [swift-dev] [SR-710][RFC] Automatically detecting XCTest test methods on Linux: Reflection? SourceKit?

There is libxpc from NextBSD: https://github.com/NextBSD/libxpc You’d still need to implement Mach IPC on top of something though. — Luke > On 10 May 2016, at 12:35 PM, Brian Gesiak via swift-dev > wrote: > > Thanks for the feedback, everyone! > > Porting

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

As I think I mentioned before, you’ll probably have more luck porting the Apple runtime [1] to Linux than getting it to work with the GNUstep runtime. — Luke [1] http://opensource.apple.com/source/objc4/objc4-680/ > On 31 Mar 2016, at 6:02 AM, Iliya Trub via swift-dev > wrote: > > Of course,

Re: [swift-dev] swift_retainCount in CoreFoundation

Looks like it was killed in d430c06f. > On 5 Jan 2016, at 7:10 AM, Tony Parker via swift-dev > 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 s

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

> I think those are all pretty reasonable. The pipeline for changes is > bi-directional; however it will have to get reviewed by the component owner > and undergo our process to change API behavior internally. I am fairly > certain that this is an edge case that hasn’t even been thought of and

[swift-dev] Compiling SIL with swiftc

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 undeclared type 'SomeProtocol' %23 = metatype $@thin SomeProtocol.Protocol

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

> On 31 Dec 2015, at 2:10 PM, Philippe Hausler wrote: > > I think those are all pretty reasonable. The pipeline for changes is > bi-directional; however it will have to get reviewed by the component owner > and undergo our process to change API behavior internally. I am fairly > certain that

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

> On 31 Dec 2015, at 11:25 AM, Luke Howard via swift-dev > wrote: > >> I really want to merge in the rest of the coders; so lets go ahead and omit >> the mangling stuff and leave it just as the Foundation classes . That will >> be a huge win in my book, it gives us

Re: [swift-dev] Linker script on Linux

> On 31 Dec 2015, at 12:33 PM, Joe Groff wrote: > > >> On Dec 30, 2015, at 1:24 AM, Luke Howard via swift-dev > <mailto:swift-dev@swift.org>> wrote: >> >> Per [SR-404], anything that consumed libFoundation could not dynamically >> cast to a Fou

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

> I really want to merge in the rest of the coders; so lets go ahead and omit > the mangling stuff and leave it just as the Foundation classes . That will be > a huge win in my book, it gives us something that is testable and functional > enough to do some pretty impressive demonstrations of arc

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

> On 31 Dec 2015, at 10:24 AM, Philippe Hausler wrote: > > Yep and that is why I am holding off on merging this just yet until we can > get something up and rolling from the stdlib to support this. > For now we could just limit these to the list of hand coded class to string > conversions and

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

>> 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 Sorry I mean NSClassFromString(). I thought indirecting the lookup

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

> On 31 Dec 2015, at 5:03 AM, Joe Groff wrote: > >> >> 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 TypeMetadataAcce

[swift-dev] Linker script on Linux

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 conformances table. (There’s also some weird issue where dlsym() seems to return the

[swift-dev] ExistentialMetatypeType assertion failure on Linux

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.EnableObjCInterop || *repr != MetatypeRepresentation::ObjC); in Existent