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

[Joe Groff]

> On Dec 11, 2015, at 11:41 AM, Geordie Jay <geojay at gmail.com> wrote:
> 
> 
>>> On Dec 11, 2015, at 9:03 AM, Geordie Jay <geojay at gmail.com <mailto:geojay at gmail.com>> wrote:
>>> 
>>> Hi Joe,
>>> I was just commenting on your @_cdecl commit on GitHub but I’ll keep the discussion here.
>>> 
>>> I was wondering what it is about your implementation that makes it rely on ObjC interop, as you noted. And whether this dependency can be removed for a quick and dirty proof of concept, or whether it’s something more fundamental than that?
>> 
>> It's mostly because that's how the parameter type validation logic I borrowed from @objc works, and I didn't have time to change it. The code for @cdecl has to be refined to support a "C-only" model, or maybe just only require ObjCInterop and 'import Foundation' when ObjC-specific constructs are used.
> 
> I’d like to have a look at making a simple C-only model of this. Compiler hacking is new to me though so I’ll be stabbing in the dark for a while. Can you elaborate as to whether you're referring to the block starting at line 4108 in 'lib/Sema/TypeCheckDecl.cpp’, or something else? Presumably there are already relevant type-checking routines for Swift's @convention_c functions, no?

The checking code is in the "isRepresentableInObjC" family of functions around there, yeah. @convention(c) didn't need to distinguish C from ObjC on Darwin platforms, since ObjC and Foundation are always available there, so we didn't bother trying to separate them. You could probably get started by just disabling the checks for Foundation and ObjC interop altogether and avoiding touching any class, block, or CF types (which probably is easy on Android).

>>> In this (admittedly very simple) example, the author just calls the mangled name from C and appears to get away with it:
>>> http://romain.goyet.com/articles/running_swift_code_on_android/ <http://romain.goyet.com/articles/running_swift_code_on_android/>
>>> 
>>> Makes me wonder whether the @_silgen_name approach wouldn’t suffice after all for a proof of concept?
>> 
>> They're getting lucky. Swift function ABIs happen to coincide with C function ABIs in some cases, but this can't be relied on, and will probably break soon when we switch over the Swift-specific calling convention in LLVM.
> 
> Are we talking about safety / type checking? I mean about validating that we’re not asking for e.g. a Swift Struct in our @_cdecl function? Or is there something else at play? The goal of Swift is obviously to be safe, but since I’m so new to this, what I’d like to see first is something that ‘works' at all, and continue on the safe side after that. I’m just after a proof of concept for now.

I'm talking about linkage safety. If swiftc exports a swift function with a certain symbol name, and C code links against it, we don't want to guarantee they'll use the same calling convention, unless the function is explicitly exported with an attribute saying it uses the C calling convention.

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151211/087566db/attachment.html>