Prevent unused dynamic libraries from blocking WASI build

[SDGGiesbrecht]

This prevents SwiftPM from hitting a fatal error in TSC until after it is known whether a dynamic product is actually used.

@MaxDesiatov

Motivation:

Right now, if any package in the graph contains a dynamic library product, SwiftPM crashes when building for WASI, even if the product is not used by any target. This happens because SwiftPM attempts to compute the path of the resulting dynamic library before it checks whether it will actually need to build it or not.

Modifications:

This PR takes every query of the dynamic library path that happens early enough to cause problems, and skips it if the destination is WASI.

Queries of the same property that occur after unused products have been filtered out remain as they were, and so the fate is unchanged if you actually attempt to build a dynamic library product.

A test has been added to detect any future regressions; it fails without the rest of the changes.

Result:

Unused dynamic libraries no longer block WASI builds.

[neonichu]

This seems pretty ugly to me.

I think we should instead find a way to filter out dynamic products entirely when producing the build plan.

[SDGGiesbrecht]

That is what I though at first too; the downside turned out to be that its complete absence starts chain reaction of other breakage, particularly regarding diagnostics. In a perfect world, Triple’s dynamicLibraryExtension would have been optional, but to make that change now would be colossally invasive.

I am not sure why this sort of information is being computed greedily in the first place only to be discarded later. Maybe that is the real issue here, but I have not yet been able to fully unwind in my head what is happening when and why for that part of the loading process.

I suppose alternatively, if @MaxDesiatov knows what the hypothetical extension would eventually be, then we could specify it in TSC instead of the fatalError error and the problem would just vanish.

[SDGGiesbrecht]

Hmm... While the official status appears to be about equivalent to an underscored feature in Swift, Emscripten’s documentation recommends the extension .wasm. And at least one blogger uses that in his raw clang example too. Could we just use that in TSC for now, @MaxDesiatov? We can easily change it later, but having something right now would be helpful.

[SDGGiesbrecht]

I have tested SwiftPM on top of swiftlang/swift-tools-support-core#311, and can confirm that it completely solves the problem on its own. So if that PR is accepted, this one becomes moot.

[MaxDesiatov]

CC @kateinoigakukun

[MaxDesiatov]

Specifying .wasm extension in TSC seems like a reasonable solution to me.

[kateinoigakukun]

Specifying .wasm extension in TSC seems like a reasonable solution to me.

I agree. c.f. rustc also uses .wasm as dll suffix https://github.com/rust-lang/rust/blob/a8272f23cc121cc3e98f3148c8dab532decc7b90/compiler/rustc_target/src/spec/wasm_base.rs#L78

[SDGGiesbrecht]

swiftlang/swift-tools-support-core#311 was merged instead.