Move to Swift 5.1 / Xcode 11

[freak4pc]

This bumps minimum Swift version to 5.1, updates CI, removes all deprecated methods (as we don't need to support if we're bumping major), and removes some unnecessary return statements as part of SE-0255.

SPM-related tests are still failing, seems the v5_1 version isn't recognized for some reason. Could be wrong version of SPM, will need to check.

[freak4pc]

Ok, Unix tests are good now.

Interestingly, URLSession and other APIs have moved from Foundation to a framework called FoundationNetworking: https://github.com/apple/swift-corelibs-foundation/blob/a264bfd40af8412161cdc05be11c1cf35f6a56f1/Docs/ReleaseNotes_Swift5.md#dependency-management

@kzaher I've commented a test here that seems to deadlock on Unix. I really don't have enough knowledge to debug this but it seems only the first concurrency task actually runs. Any ideas? This PR is blocking any other PR related to this release.

Deadlocked test:

RxSwift/Tests/RxSwiftTests/Observable+ObserveOnTests.swift

Lines 444 to 493 in cce95dd

	func testObserveOn_EnsureTestsAreExecutedWithRealConcurrentScheduler() {
	var events: [String] = []
	let stop = BehaviorSubject(value: 0)
	let scheduler = createScheduler()
	let condition = NSCondition()
	var writtenStarted = 0
	var writtenEnded = 0
	let concurrent = { () -> Disposable in
	self.performLocked {
	events.append("Started")
	}
	condition.lock()
	writtenStarted += 1
	condition.signal()
	while writtenStarted < 2 {
	condition.wait()
	}
	condition.unlock()
	self.performLocked {
	events.append("Ended")
	}
	condition.lock()
	writtenEnded += 1
	condition.signal()
	while writtenEnded < 2 {
	condition.wait()
	}
	condition.unlock()
	stop.on(.completed)
	return Disposables.create()
	}
	_ = scheduler.schedule((), action: concurrent)
	_ = scheduler.schedule((), action: concurrent)
	_ = try! stop.toBlocking().last()
	XCTAssertEqual(events, ["Started", "Started", "Ended", "Ended"])
	}

[kzaher]

Hi @freak4pc ,

I don't think we can simply remove that test. As far as I can tell this is not a deadlock but a real regression in either OperationQueue or in OperationQueueScheduler on Linux.

Here is a proof.
https://github.com/ReactiveX/RxSwift/tree/debugging-concurrent-scheduler-hang

I've added prints. let concurrent = { () -> Disposable in is not being executed twice when doing _ = scheduler.schedule((), action: concurrent) twice in succession.

If you just checkout ed90e60 you will see it prints.

Before
Dispatching 1
Dispatching 2
Dispatching 3
Started
Waiting

If there were 2 threads concurrently executing concurrent there would be two Before prints. But there aren't.

If somebody has more information that would be great.

I definitely don't see a reason to remove our test, because as far as I can tell it is working properly.

If we find that this is Apple's bug with OperationQueue we should put a conditional compilation to use normal ConcurrentDispatchQueueScheduler vs OperationQueueScheduler for this version of Swift compiler and Linux os.

[kzaher]

Oh, one can easily test this on https://github.com/ReactiveX/RxSwift/tree/debugging-concurrent-scheduler-hang if they have docker locally.

docker pull swift
./scripts/test-linux.sh

[kzaher]

@freak4pc I can't explain why cocoapods fail with your branch.

Develop branch succeeded 13 days ago.
https://travis-ci.org/ReactiveX/RxSwift/builds/600083555

You probably changed something regarding CocoaPods configuration in this branch.

[freak4pc]

I made no changes to CocoaPods configuration. I think Travis used to hold some sort of cache perhaps and it was cleared. It seems pod repo update basically does nothing and I'm not sure why.

[freak4pc]

@kzaher This finally works. Would be great to merge this so we can start accumulating more content on top of RxSwift 6.0.0-beta.1

[freak4pc]

Hey @kzaher - I know you're very busy, but wondered if you have time to look into this? I'd like to accumulate as much content as possible into a releasable beta

[kzaher]

I think the cleanup in general makes sense. Thanks @freak4pc . Sorry for waiting so long, I've extremely busy lately.

[kzaher]

I've been reading about this, geez. I don't know how does this affect ABI. Does this mean that if this becomes magically available on {i,mac,tv,watch}OS that it will break our ABI?

If we don't have a better workaround, it's probably fine.

[freak4pc]

I'm really not sure, but there's no other solution right now.
About ABI stability, @keith has a PR around this, starting with removing all of these individual imports in favour of importing all of Foundation. WDYT of that? #2103

[kzaher]

Interesting, glad you've been able to solve it :)