While Swift probably also crashes in an incomprehensible way when it runs out of memory, in your example, what's crashing is the linker, which the Swift project doesn't control. I don't think exit status 254 is something that tells us this unambiguously; at best we could emit a diagnostic like "possible out-of-memory condition", but that sort of notice can sometimes be really misleading.

Comment by christopher biagioni (JIRA)

So the two options at present are to either not really say anything about what actually caused the crash or risk saying something that's not the cause at all. Hmmmm. How would a programmer be expected to diagnose an issue like this definitively?

One option is to emit a diagnostic that is essentially a list of recommendations that lend direction towards resolving the issue rather than attempting to say what it was definitively; and one of those recommendations could be something along the lines of "ensure enough memory is available for linking". This way some of the common items are addressed before a programmer turns to the community for guidance — perhaps the amount of time saved from people ensuring they're in compliance with the recommendations results in a significantly lower number of people turning to the community with 254 crashes, and the time saved by the team because of that is greater than the time it would take to devise a quality list of recommendations.

The problem is that 254 doesn't mean anything in general. There's limited standardization for exit codes in the first place, and 254 is not covered by what does exist. We know that the linker apparently called exit rather than crashing, but it did so without generating any diagnostic output. If 254 is a reliable signal for OOM, that's presumably specific to a particular release of a particular linker, and there are a lot of different linkers for Linux. So we'd really just be guessing wildly.

We'd probably be better off asking the linker to look into why they manage to call exit, but do so without any output. Although it's possible that the exit isn't even in their source code; maybe some library is calling `exit(254)` on their behalf.