Swift compiler doesn't support turning off whole module optimization on certain projects

[dabrahams]

Description

I know, I know, this is really an SPM issue. But the SPM people think I should file it here. I'm just doing what they asked. I hope we can avoid 👉 👈

This matters to me because of #70979, which I need to work around.

Reproduction

• swift package init --type executable
• add swiftSettings: [.unsafeFlags(["-no-whole-module-optimization"])] to the executable target
• swift build -c release

Expected behavior

build completes successfully

Environment

swift-driver version: 1.87.3 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)
Target: arm64-apple-macosx14.0

Additional information

No response

[AnthonyLatsis]

@MaxDesiatov Hello Max, I hope you don’t mind me tidying up the labels.

WMO control strikes me as as much a Swift build system feature as -c release. What exactly do you think the compiler is lacking in this situation? Does such a feature warrant a coordinated effort?

[dabrahams]

@AnthonyLatsis I am assuming your entire message (not just the first sentence) is directed at @MaxDesiatov. No need to respond unless I've got that wrong. Thanks.

[MaxDesiatov]

What exactly do you think the compiler is lacking in this situation?

IDK, I'm not a compiler engineer and I don't have enough knowledge to specifically point to an area of code in the compiler that's responsible for this. As clarified in the issue originally created on the SwiftPM repository, SwiftPM is just passing -no-whole-module-optimization flag to swiftc verbatim (unlike -c release), there's nothing we can do about it on SwiftPM side if swiftc doesn't handle this flag well. And that's the reason we allow these ad-hoc optimization settings to be passed to swiftc from SwiftPM only via unsafeFlags, to warn users they'd be relying on specific swiftc tweaks at their own risk.

[dabrahams]

Forgive me, but although you may have tried to explain something in the original issue, nothing was clarified (as in actually made clearer) there. It's as much a mystery to me why we're here as ever, and I'm pretty sure @AnthonyLatsis is in the same boat. So please try not to assume that whatever message you've been trying to send was actually well-formed enough for anyone else to understand.

I don't know why you think swiftc is failing to “handle the flag well,” or even what you mean by that phrase.
The dependencies file being complained about is something that a build system would look for, not a compiler. The only thing I can imagine that you mean (and because you really haven't clarified anything, I'm only guessing here, which runs the risk of wasting everybody's time) is that the build system expects the compiler to have generated the dependencies file, but it does not. If I've guessed correctly at what you mean, the problem comes down to what the contract is between the compiler and the build system, and/or what promises swiftc makes to the world about generating such files.

I suppose there's one other possibility, which is that the dependencies file isn't used by the build system at all, but compiler actually expects the dependencies file to exist when linking one module into another? Again, I'm just guessing, unfortunately.