> On Oct 12, 2016, at 3:46 PM, Greg Parker <gpar...@apple.com> wrote:
>> On Oct 12, 2016, at 11:11 AM, John McCall via swift-dev <email@example.com
>> <mailto:firstname.lastname@example.org>> wrote:
>>> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev <email@example.com
>>> <mailto:firstname.lastname@example.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.)
That's nice in theory, but it creates a build dependency between the C++ and
Swift sources wherever we want to do this.
swift-dev mailing list