[swift-corelibs-dev] NSCoding methods

[Philippe Hausler]

Responses inline:

> On Dec 29, 2015, at 5:03 AM, Luke Howard <lukeh at padl.com> wrote:
> 
> OK, so I’ve cleaned up the commit history for the NSCoding branch, you can find it here still:
> 
> https://github.com/lhoward/swift-corelibs-foundation/tree/lhoward/nscoding <https://github.com/lhoward/swift-corelibs-foundation/tree/lhoward/nscoding>
> 
> I haven’t opened a pull request as I’d like to get it working on Linux first. Having a bit of trouble though. (I’m using Ubuntu 15.10 with the latest snapshot.)
> 
> Firstly, build-wise:
> 
> * Changing anything in Foundation/ seems to trigger a recompile of everything Swift. Is there a way to do correct dependency analysis? My clock is OK.

Yep; probably should be a “known issue” the ninja script will emit the other swift files as deps since there might be cross file dependencies - it is a bit slow when the compiler is in debug mode

> 
> * swift/utils/build-script with —debug-foundation still seems to build a release version. I worked around by building everything debug, but that takes up a lot of disk space.

My trick that I do is I will build a release build and then hand edit the `.configuration` file of Foundation to be debug; so that way the next `ninja reconfigure` will reconfig it as debug and give juicy debugging info but the rest of the runtime and compiler is in release mode. (I have been considering adding this as a specialized reconfigure option

> 
> * lldb crashes all the time when printing variables (actually I also see this on OS X as well with the snapshot)

po or p?

> 
> Related to testing:
> 
> * Something weird is going on with casting over which completely breaks NSKeyedArchiver. I can reproduce it with the following:
> 
>     let foo = (NSMutableArray() as? AnyObject) as? NSCoding
> 
> which the compiler tells me always succeeds (as I believe it should), but at runtime returns foo==nil. No issue if it is a locally defined class that conforms to NSCoding. It’s failing in _dynamicCastToExistential()’s check for _conformsToProtocols() but I haven’t dug deeper yet.
> 
> FYI: my LD_LIBRARY_PATH is pointing to the right libswiftCore/libFoundation. I removed the module maps for Foundation/CoreFoundation from the snapshot directory.

The removal of the module map is usually only needed when building directly to an installed root. Most of the build process for incremental builds don’t need to have module map removal shenanigans.

> 
> * Subclassing NSObject fails outside Foundation (see SR-272) is also an issue but not a blocking one
> 
> — Luke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151229/6000f966/attachment.html>