> On Oct 13, 2016, at 9:30 AM, Michael Gottesman <mgottes...@apple.com> wrote: >> On Oct 12, 2016, at 4:36 PM, John McCall via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >>> On Oct 12, 2016, at 3:46 PM, Greg Parker <gpar...@apple.com >>> <mailto: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. > > 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. > > I am not sure if there is a clang mode for diffing/comparing declarations > like these though.
If we have to have a .def file, just consuming it for assertions in IRGen seems like the way to go. John. > > Michael > >> >> John. >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org <mailto:swift-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-dev >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
