Enums and Protocol conformance causes segfault on android

[ephemer]

I finally managed to get my own compiled version of the swift toolchain working with the help of your swiftc-android script. I am now testing some code examples to see what works.

Compiling and linking multiple swift files seems to be fine.
Glibc seems to work fine (avoiding arc4_random of course ;) - pow, sqrt etc. at least..

The current issue is that even a simple enum like this one:

enum MusicalNote {
    case C, Csharp, D, Dsharp, E, F, Fsharp, G, Gsharp, A, Asharp, B
}

causes a segfault at runtime on android, even if no enum members are instantiated (it is enough to just have the above in any file you compile). I wouldn't have a clue how to start tracking this down. Maybe I should rebuild a debug version of the toolchain to try to get some more information about the crash?

I also tested a struct conforming to CustomDebugPrintable and Equatable and also got a segfault. I haven't narrowed that case down yet but it may well be related.

[zhuowei]

Thank you so much for the report! I'll try to get the stdlib testcases running when I have a bit of time to try to track down the source of this error.

I would guess that the source of the error is caused by not properly loading the conformance data for the current executable (enums generate conformance data; "hello world" doesn't, and I would assume structs conforming to protocols also generate conformance data).

currently on Android, like Linux, the executable dlopen()s all libraries, looks for conformance data, and if found loads it before dlclose()ing. However, dlopen has a special case - one must pass null for the current executable; I'm not doing that yet on Android so that's probably the problem. (It's a FIXME in stdlib/public/runtime/Casting.cpp)

For compiling as debug: since this occurs in the stdlib you can try compiling only the stdlib as debug (the build script supports this)

[zhuowei]

Fixed. (By the way, you seem to be very interested in this project: I can give you commit access to the repo if you want)

[ephemer]

Wow, great work on pushing a fix so quickly! Yes I'm very interested, have been working on this every day for a week and a half now (well I guess that's since swift went open source :)

Push access would be great, I'm new to compiler hacking and I'm fairly new to C++ too so I'm not sure I have a huge amount to contribute to that side of things. I think I can definitely help out in making the UX smooth and the build repeatable though. It'd be good to be able to make internal branches and make internal pull requests without needing to fork the whole repo.

Assuming this fix works, I'm going to start on the @_cdecl side of things (see http://GitHub.com/Apple/swift/pull/3), to get the JNI integration as smooth as possible. At the moment it's printing Objective C headers for C funcs, but manually changing those to C types seems to have worked so far (which makes sense because e.g. NSInteger is just a platform dependent int). So I want to remove the objc interop dependency there and get it printing pure C headers