> 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 Wrangler
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
