Building a module for a non-ABI stable platform fails when Swift stdlib modules aren't built w/Library Evolution

[stmontgomery]

Description

There is an effort in progress to begin building Swift stdlib modules (including supporting modules like _StringProcessing and _Concurrency) without Library Evolution (LE) on non-Apple platforms. Historically, these modules have had LE enabled even on non-Apple platforms. But with these changes, clients which already have LE enabled on such platforms hit new build errors such as the following:

<unknown>:0: error: module '_StringProcessing' was not compiled with library evolution support; using it means binary compatibility for '_TestDiscovery' can't be guaranteed
<unknown>:0: error: module '_Concurrency' was not compiled with library evolution support; using it means binary compatibility for '_TestDiscovery' can't be guaranteed

Swift Testing is one project affected by this: see swiftlang/swift-testing#1307

This issue is tracking a resolution in the compiler. @xymus suggested it may be possible to resolve this by suppressing this diagnostic on platforms which don't support ABI stability. Additionally, he mentioned it may make sense to reduce the severity of that diagnostic on ABI stable platforms from error to warning.

Additional information

No response

[stmontgomery]

cc @compnerd @etcwilde

[etcwilde]

Even beyond ABI stability (I'm not sure if we're talking about calling-convention, runtime library, or full bidirectional binary compatibility), I don't know that it makes sense for static archives to ever have library evolution enabled. The process can't find itself running against a different version since it's embedded in the binary itself. If it does, that means that the process has at least two copies of the library and we've violated ODR and now we're getting into UB territory.

[xymus]

The PR above #84373 should downgrade the error to a warning and at least unblock this effort. We should look to silence it completely in a case like this, however I don't know what's the best approach here.