The place to look here is in the (multiple) implementations of TaskQueue under swift/lib/Basic, and its use in swift/lib/Driver/Compilation.cpp.

@ddunbar, it'd be easier for a newcomer to pick up this starter task if you included a command-line invocation that demonstrates the problem. Do you have one handy? 🙂

swiftc -Xfrontend -debug-crash-immediately empty.swift should work.

Comment by Markus Chmelar (JIRA)

swiftc -Xfrontend -debug-crash-immediately empty.swift -parseable-output produces

...
"kind": "signalled",
"name": "compile",
"pid": 2835,
"output": "0 swift ......,
"error-message": "Illegal instruction: 4"
...

Isn't the error-message the signal? Or do you mean to add the raw number of the signal to the output as well?

I think the request is for the raw number, yeah. Using the output of strsignal isn't very stable.

Comment by Chris Double (JIRA)

This looks relatively easy to fix for the Unix TaskQueue implementation - it has the signal value, calls strsignal on it and passes the string to the callback. Extending the callback signature to include the integer signal value would enable it to receive it and be added to the parseable-output.

The Default TaskQueue implementation uses the return value of llvm::sys::Wait to identify if a signal occurred. The Unix implementation of that function has the signal value, calls strsignal and then returns '-2' with the error message set. The actual signal integer is discarded. The Windows implementation doesn't have a signal value at all - it sets the error message explicitly to a couple of hard coded strings.

Given this, what should the value of the raw number of the signal be in the parseable output on Default TaskQueue backends? Not included at all and just have it added if the Unix TaskQueue implementation is used?

That would be my preference, and then we document that the information may not be available on all platforms (but that if it is ever provided it should not be removed in future versions of the compiler).

Comment by Matthew Carroll (JIRA)

#6787