I've been working on bisecting this between the 07-15 and 07-22 toolchains, and I've been able to build the 07-15 swiftlang sources (but it did require a cherry-pick of b7ec9c84. I'm using the buildbot_linux preset, which looks like it includes both --foundation and --install-foundation flags.

The problem is that after the compiler is built, I go to compile the reproducer, and it fails with error: no such module 'Foundation'.

Am I missing some kind of link step to make sure the newly built Foundation is discoverable?

cc @parkera @jmschonfeld

I'm seeing this issue as well with NSThread

Moving this issue to the compiler repo, since it seems like the investigation should continue in that space.

Bump. Has this landed on anyone specific for triage? Anything I can do to help on my end?

The note points to the mutex member being unreadable from the client side. From the NSLock sources it looks like mutex can’t be read because its type relies on pthread_mutex_t which comes from an @_implementationOnly dependency. Using @_implementationOnly in a non-resilient module is unsupported and strongly discouraged, it can cause this kind of unreliable behavior without being detectable by the compiler.

@clackary (Hi!) as a workaround, importing CoreFoundation from the client should force loading that module and allow to read mutex. On my local Linux machine it allows the reducer to build.

@parkera this will need a fix in the swift-corelibs-foundation project. Can we make sure the type of NSLock.mutex doesn’t rely on anything behind an @_implementationOnly import?

Please don't import CoreFoundation on Linux. It is (supposed to be) an implementation detail.

Will switching to internal import fix this?

Yes adopting internal import should work here.

I'd like to double check with some people before we merge it -- but I put up a PR for now.