[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

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

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) // <— this causes the compiler to assert there. > On Dec 30, 2015, at

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)

[swift-dev] Should we remove _customContainsEquatableElement from stdlib?

After reviewing the code of stdlib I found no one actually implements _customContainsEquatableElement: 1. Its default implementation in `SequenceType` just returns nil. 2. The implementation in `Set` delegates to `contains` which is bad because it reverses their relationship: the default implemen

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 TypeMetadataAccessor = @convention(c) () -> AnyClass? >> >> The a

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] Should we remove _customContainsEquatableElement from stdlib?

On Wed, Dec 30, 2015 at 8:34 PM, Ling Wang via swift-dev wrote: > After reviewing the code of stdlib I found no one actually implements > _customContainsEquatableElement: > 1. Its default implementation in `SequenceType` just returns nil. > 2. The implementation in `Set` delegates to `contains` w

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] ExistentialMetatypeType assertion failure on Linux

> On Dec 30, 2015, at 3:21 PM, Joe Groff via swift-dev > wrote: > > >> 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 yest

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

Prior to this e-mail, it wasn't clear to me that there were two different "unowned" concepts. +1 in favor of the rename. --Emanuel On Tue, Dec 29, 2015 at 3:18 PM, Michael Gottesman via swift-dev wrote: > One form of overloading that we currently have at the SIL level are the > notions of the

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

> On Dec 30, 2015, at 3:55 PM, Luke Howard wrote: > > >> 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

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] Should we remove _customContainsEquatableElement from stdlib?

Got it. `contains` is only declared in extension. Interesting workaround. Thanks. > On Dec 30, 2015, at 4:45 PM, Dmitri Gribenko wrote: > > On Wed, Dec 30, 2015 at 8:34 PM, Ling Wang via swift-dev > wrote: >> After reviewing the code of stdlib I found no one actually implements >> _customCont

Re: [swift-dev] Should we remove _customContainsEquatableElement from stdlib?

FWIW, once we have conditional protocol conformance (`extension ... : Proto where ...`), and if we get rid of the circular protocol inheritance limitation (two protocols that inherit from each other, which should in theory be fine), then we can say something like protocol EquatableSequenceType

[swift-dev] Where are @_attributes documented?

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. Where are they documented? ___ swift-dev mailing list swift-d

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] 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 > > wrote: >> >> Per [SR-404], anything that consumed libFoundation could not dynamically >> cast to a Foundation protocol because the build script was mis

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 something that is testable

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

> On Dec 30, 2015, at 6:57 PM, Luke Howard wrote: > > >> 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

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] Where are @_attributes documented?

Yes I’m submitting patches to stdlib. Thanks for pointing me to the doc folder. > On Dec 30, 2015, at 7:35 PM, Joe Groff wrote: > > >> 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 >> @_attribu