[c-interop] Make Extern a suppressible language feature

[tshortli]

Fixes building the standard library's .swiftinterface with older Swift compilers.

[tshortli]

Addresses regression from #69352.

[tshortli]

@swift-ci please smoke test

[kateinoigakukun]

@tshortli Thank you for fixing this 🙏 I don't know when older compiler parses newer stdlib's module interface, but is it safe to change the symbol name by suppressing the attribute depending on whether the compiler supports the feature?

Looks like other suppressible language features are not ABI-affecting features but @_extern is.

[tshortli]

As a rule of thumb, the most recently released Swift compiler toolchain should be able to successfully compile the Standard library module from its .swiftinterface. This is needed to support workflows where users have an older, stable toolchain installed but update to more recent SDKs with a newer standard library. The most important aspect of supporting this workflow is simply that the interface is buildable (that is, it typechecks and serializes successfully). Generally speaking, newly added language or stdlib features don't need to work in this configuration, they just need to not prevent the module from building.

[tshortli]

If @_extern here affects the ABI of something that was existing and therefore users in this configuration might actually depend on then I suppose your concern is valid. If that's the case I'm afraid we need to revert #69352 and go back to the drawing board with how to implement it in a way that does not break the stdlib interface for older compilers.

[kateinoigakukun]

Thanks for your detailed explanation. Those functions attributed with @_extern are only referenced from debugger, so hopefully it just breaks LLDB's language swift refcount command. To avoid the breakage, I think the safest way would be to keep the old wrong (but works on most platforms) way like below:

#if compiler(>=5.3) && $Extern
@_extern(c, "swift_retainCount")
#else
@_silgen_name("swift_retainCount")
#endif
@usableFromInline
internal func _swift_retainCount(_: UnsafeMutableRawPointer) -> Int

[tshortli]

It looks to me like the functions that gained @_extern(c) in #69352 are only the retainCount family of functions, which are only ever used from the debugger right? If that's the case, I'm inclined to say that it's unfortunate but not a showstopper that they be broken in the configuration where an older compiler is being used. However, we should fix this properly in a follow up. It looks to me like maybe a proper fix for this would be to print the @_silgen_name(<name>) attribute instead of @_extern(c, <name>) for the branch where the @_extern attribute is not supported. Does that make sense? It seems like it would return things to the status quo from before #69352.

[lorentey]

Looks good! Thank you for following up on this. 👍

[kateinoigakukun]

It looks to me like the functions that gained @_extern(c) in #69352 are only the retainCount family of functions, which are only ever used from the debugger right?

Yes, that's correct.

If that's the case, I'm inclined to say that it's unfortunate but not a showstopper that they be broken in the configuration where an older compiler is being used.

Yeah, that's reasonable. If it's not critical path, I think we can accept the breakage.

It looks to me like maybe a proper fix for this would be to print the @_silgen_name() attribute instead of @_extern(c, ) for the branch where the @_extern attribute is not supported. Does that make sense?

Hmm, they have slightly different ABI semantics and we can expect there is no other usage of @_extern except for stdlib at the moment, so falling back as a part of compiler output might be too much.

Anyway, this approach seems reasonable to me. Thanks again!

[tshortli]

@swift-ci please smoke test macOS

[tshortli]

@swift-ci please smoke test Linux

[tshortli]

@swift-ci please smoke test