> 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 <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >>> On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev <swift-dev@swift.org >>> <mailto: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.)
That's nice in theory, but it creates a build dependency between the C++ and Swift sources wherever we want to do this. John.
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
