> On Oct 12, 2016, at 11:11 AM, John McCall via swift-dev <swift-dev@swift.org> 
> wrote:
>> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev <swift-dev@swift.org> 
>> wrote:
>> I just tracked down a bug due to C++ code in the Swift runtime code trying 
>> to interface with standard library code written in Swift, but getting the 
>> ABI slightly wrong and leading to some nasty hard-to-reproduce heisenbugs. 
>> While I've narrowed down the bug in this specific case, it seems like this 
>> is a potentially continuing source of maintenance bugs, especially as we try 
>> to bring up the Swift calling convention in the coming year. I'm wondering 
>> if there's anything we could do to help validate that C++ and Swift code in 
>> the runtime is correctly interfacing. We could at least check that we're 
>> passing the right number of arguments by comparing the LLVM IR of the 
>> runtime and stdlib, perhaps, though this would have to be a fuzzy type-level 
>> match since Clang and Swift aren't normally going to agree on the exact 
>> pointer types of arguments.
> One potential approach:  make a def file with the names and (somehow 
> abstracted) expected prototypes of Swift functions defined by the standard 
> library but used by the runtime.  In the runtime, use that to autogenerate a 
> header.  In IRGen, add a +Asserts check before finalizing the module that, if 
> there are any functions with those names, they do match the abstract 
> prototypes.  Hope that all such interactions use only portable IRGen 
> call-lowering patterns.

Or perhaps have a swiftc mode that generates a C prototype for every function 
marked with @_silgen_name, and use that to build an autogenerated C header. 
(I.e., skip the def file and use the swift file as the canonical description.)

Greg Parker     gpar...@apple.com <mailto:gpar...@apple.com>     Runtime 

swift-dev mailing list

Reply via email to