> On Oct 12, 2016, at 11:11 AM, John McCall via swift-dev <firstname.lastname@example.org>
>> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev <email@example.com>
>> 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