Linux specific regression -- error: cannot inherit from class 'NSLock' because it has overridable members that could not be loaded

[clackary]

The following code snippet builds successfully with the 2024-07-15 nightly toolchain, but fails to build with 2024-07-22. I'm not sure how to check or verify this was caused by the switch to swift-foundation, but the timing seems to line up.

import Foundation

class FooLock: NSLock {}

Actual behavior:

/project/repro.swift:3:7: error: cannot inherit from class 'NSLock' because it has overridable members that could not be loaded
1 | import Foundation
2 | 
3 | class FooLock: NSLock {}
  |       |- error: cannot inherit from class 'NSLock' because it has overridable members that could not be loaded
  |       `- note: could not deserialize 'mutex'
4 | 

Worth noting that it does seem specific to Linux, because the same snippet builds successfully with recent toolchains on macOS.

Expected behavior:
Code builds successfully.

Configuration:
OS: Linux Ubuntu 22.04
Toolchain: swift-DEVELOPMENT-SNAPSHOT-2024-07-22-a-ubuntu22.04-aarch64 or newer

[clackary]

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

[daltonclaybrook]

I'm seeing this issue as well with NSThread

[parkera]

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

[clackary]

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

[xymus]

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?

[parkera]

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

[parkera]

Will switching to internal import fix this?

[xymus]

Yes adopting internal import should work here.