Fix NSLock/Thread subclassing issues

[jmschonfeld]

Currently, NSLock/Thread cannot be subclassed due to the following (or related) issues:

error: cannot inherit from class 'NSLock' (compiled with Swift 6.1) because it has overridable members that could not be loaded in Swift 5.10
Could not deserialize type for 'mutex'
Caused by: module 'CoreFoundation' was not loaded

This is because NSLock/Thread have members whose types come from pthread.h. CoreFoundation currently imports pthread.h in its public headers, and this led the compiler to believe that pthread.h came from the CoreFoundation module and not the SwiftGlibc clang module. This results in a failure because due to the @_implementationOnly import, CoreFoundation is not loaded by clients.

To resolve this, we need to ensure the compiler realizes that pthread.h and the types within come from the SwiftGlibc clang module rather than CoreFoundation. To do this, we import the SwiftGlibc.h header file (from the SwiftGlibc clang module) before importing pthread.h. However, SwiftGlibc.h is not in the default header search paths so we need CMake to lookup the path for SwiftGlibc.h (by asking the compiler) and add the search path when building CoreFoundation. We don't need to do this for the SwiftPM build since it seems that the modules are resolved differently and we do not have this issue (which is also why we can't add a unit test for this).

Resolves #5108, rdar://137716518

[jmschonfeld]

@swift-ci test

[jmschonfeld]

Using a toolchain built with this change, it seems that this resolves the issue for NSLock and its subclasses, but it did not resolve the issue for Thread:

error: cannot inherit from class 'Thread' (compiled with Swift 6.1) because it has overridable members that could not be loaded in Swift 5.10

Could not deserialize type for '_attr'
Caused by: module 'CoreFoundation' was not loaded

[clackary]

Gently bumping this, as it's still affecting the latest nightly toolchains.

[jmschonfeld]

Gently bumping this, as it's still affecting the latest nightly toolchains.

Hey, unfortunately I've yet to find a great solution to this so far. I've tried various approaches to convince the compiler that posix_thread_t and related types are owned by the SwiftGlibc clang module but so far none of those attempts have worked in all scenarios. I discussed a bit with @ian-twilightcoder and the only true solution that would fully resolve this issue (aside from fully modularizing the Linux Swift SDK) is to craft an explicit modules build for Foundation, but unfortunately that's a nontrivial change that will take some effort to figure out how to do properly. I want to try seeing if I can do some leg work to remove the usage of posix_thread_t here and store it as an Any to see if removing the types as stored properties would work, but I'm not certain if that would fully resolve the issue here either. I'll keep the issue updated if I have a moment to try to resolve this