Linux build failure -- error: cannot inherit from class 'NSLock' (compiled with Swift 6.0) because it has overridable members that could not be loaded in Swift 5.10

[clackary]

Short description of the issue:

RxSwift fails to build on Ubuntu 22.04 against 2024-07-22 nightly Swift toolchains (and newer).

Expected outcome:

Top of RxSwift main (also reproduced with 6.5.0) builds successfully against 2024-07-15 toolchain, but starting failing against newer toolchains, as of 2024-07-22 and later.

What actually happens:

/project/RxSwift/Sources/RxSwift/AtomicInt.swift:11:13: error: cannot inherit from class 'NSLock' (compiled with Swift 6.0) because it has overridable members that could not be loaded in Swift 5.10
 9 | import Foundation
10 | 
11 | final class AtomicInt: NSLock {
   |             `- error: cannot inherit from class 'NSLock' (compiled with Swift 6.0) because it has overridable members that could not be loaded in Swift 5.10
12 |     fileprivate var value: Int32
13 |     public init(_ value: Int32 = 0) {

Self contained code example that reproduces the issue:

Build errors are thrown out of Sources/RxSwift/AtomicInt.swift, but it also reproduces with a simple inherit from NSLock.

import Foundation

class FooLock: NSLock {}

RxSwift/RxCocoa/RxBlocking/RxTest version/commit

6491a16

Platform/Environment

• [ ] iOS
• [ ] macOS
• [ ] tvOS
• [ ] watchOS
• [ ] playgrounds
• [x] Linux, Ubuntu 22.04

How easy is to reproduce? (chances of successful reproduce after running the self contained code)

• [x] easy, 100% repro
• [ ] sometimes, 10%-100%
• [ ] hard, 2% - 10%
• [ ] extremely hard, %0 - 2%

Xcode version:

N/A

:warning: Fields below are optional for general issues or in case those questions aren't related to your issue, but filling them out will increase the chances of getting your issue resolved. :warning:

Installation method:

• [ ] CocoaPods
• [ ] Carthage
• [ ] Git submodules

I have multiple versions of Xcode installed: (so we can know if this is a potential cause of your issue)

• [ ] yes (which ones)
• [x] no

Level of RxSwift knowledge: (this is so we can understand your level of knowledge and formulate the response in an appropriate manner)

• [x] just starting
• [ ] I have a small code base
• [ ] I have a significant code base

[clackary]

I figured there's a chance this is a regression out of swift-corelibs-foundation, so I filed a similar issue over there -- https://github.com/apple/swift-corelibs-foundation/issues/5076

If that doesn't go anywhere, this could in theory be resolved within RxSwift by refactoring away from AtomicInt: NSLock inheritance.

[clackary]

Looks like this same failure is showing up in the swift package index testing: https://swiftpackageindex.com/builds/7B923645-D50A-4667-B129-33056F5C7599

[freak4pc]

Thanks for opening the issue! I noticed you've opened an issue on swiftlang/swift and also corelibs-foundations, so let's see what answers arise from there and we can decide on a path forward from there.

[freak4pc]

Unfortunately no response from Apple's core team so far on this.

[freak4pc]

(hoped I wouldn't have to use this label ever again)

[clackary]

Yeah, hopefully we see some movement on it soon. I've added a Linux testing config to swiftlang's source-compat-suite: https://github.com/swiftlang/swift-source-compat-suite/pull/951, in the hopes that Linux specific issues are caught sooner.

Out of curiosity though, what are your thoughts about refactoring away from NSLock in AtomicInt in favor of some of the new Synchronization stuff in Swift 6?

[freak4pc]

Yeah, hopefully we see some movement on it soon. I've added a Linux testing config to swiftlang's source-compat-suite: https://github.com/swiftlang/swift-source-compat-suite/pull/951, in the hopes that Linux specific issues are caught sooner.

Out of curiosity though, what are your thoughts about refactoring away from NSLock in AtomicInt in favor of some of the new Synchronization stuff in Swift 6?

The only way to do that safely is with a compiler time conditional because we will still want to support older compilers.

Which makes me worried we'll have to start supporting two families of locking mechanisms and the possible bugs that would stem from that.

We could possibly change the data structure to not use a subclass and that seems like a more reasonable way to get this to work (ie wrapping it in a strict with some mirroring interface). I'll try finding some time to play with it.

[freak4pc]

@clackary Check out the branch atomicint-no-inheritance, LMK what you think. I couldn't get the CI to run, but see if it works for your use case and we can sort out the CI separately.

[clackary]

Looks like that branch (actually pushed as atomicinc-no-inheritance) does build successfully against the 2024-09-25 nightly main toolchain, which is great!

[clackary]

This is still blocking a few things for us. Since the foundation side fix seems to have stalled (https://github.com/swiftlang/swift-corelibs-foundation/pull/5122), we'd like to push for a workaround if possible.

The atomicinc-no-inheritance branch does indeed work around the issue, but it looks like there's a simpler option -- import CoreFoundation in the affected file. I have verified the build issue is resolved (though I have not been able to run all tests successfully).

@freak4pc Do you have a preference for either workaround? I'd be happy to help with this.