search

swiftlang / swift

The Swift Programming Language
https://swift.org
Apache License 2.0
67.05k stars 10.33k forks source link

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

Open dabrahams opened 6 months ago

dabrahams commented 6 months ago

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

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 commented 6 months ago

@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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

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.

dabrahams commented 6 months ago

As I suspected, the diagnostic comes from the build system(swift-llbuild). Whether that is an SPM concern or a Swift concern is for the two of you to work out, I suppose.

AnthonyLatsis commented 6 months ago

Thank you for helping us chase down that error! Here is what I think we should do (not you, Dave):

@MaxDesiatov If this sounds reasonable to you, could you do the transfer? Perhaps you may also have some ideas on who to tag in the original issue.

dabrahams commented 6 months ago

Transfer this to the SPM repo. "I want SPM to support turning off WMO" is clearly a feature request that belongs there.

That's what https://github.com/apple/swift-package-manager/issues/7276 is (and what I was asking that the previous SPM issue to be repurposed for, but of course feel free to organize the issues any way you like).

AnthonyLatsis commented 6 months ago

I see, let us close this out then.

dabrahams commented 6 months ago

@AnthonyLatsis I think this leaves me stuck because I don't expect the underlying WMO bug to be easily diagnosed and it doesn't look like SPM can add a supported flag that works reliably without changes in other components.

The compiler could work around the problem by, when -no-whole-module-optimization is passed, first generating the dependencies file as though the flag hadn't been passed. In fact I think there are command-line options to do that. Yes, this same workaround could also surely be applied at the driver or swift-llbuild level… and the swift-driver project doesn't appear to be actually in use yet—the driver still lives in this repository so I guess, with apologies, I'm reopening this and filing a cross-referencing issue against swift-llbuild. I don't know what else to do.