<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 12, 2016, at 4:36 PM, John McCall via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 12, 2016, at 3:46 PM, Greg Parker <<a href="mailto:gparker@apple.com" class="">gparker@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 12, 2016, at 11:11 AM, John McCall via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On Oct 11, 2016, at 8:10 PM, Joe Groff via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class="">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.<br class=""></blockquote><br class="">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.</div></div></blockquote><br class=""></div><div class="">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.)</div></div></div></blockquote><div class=""><br class=""></div>That's nice in theory, but it creates a build dependency between the C++ and Swift sources wherever we want to do this.</div></div></div></blockquote><div><br class=""></div><div>I have not thought about the build dependency issue, but just off the top of my head, using it for building seems unnecessary. That is we could instead of using the autogenerated C header file for compilation, just generate those files for testing purposes. Then we could still use the .def file normally, but could at least have a bot that checks that things are correct.</div><div><br class=""></div><div>I am not sure if there is a clang mode for diffing/comparing declarations like these though.</div><div><br class=""></div><div>Michael</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">John.</div></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>