search

ReactiveX / RxSwift

Reactive Programming in Swift
MIT License
24.4k stars 4.17k forks source link

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 #2621

Open clackary opened 3 months ago

clackary commented 3 months ago

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

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

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:

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

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

clackary commented 3 months ago

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 commented 2 months ago

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

freak4pc commented 2 months ago

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 commented 1 month ago

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

freak4pc commented 1 month ago

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

clackary commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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