> 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.


> 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

Reply via email to