[rbi] Remove code that caused us to misidentify certain captured parameters as sending.

[gottesmm]

Specifically, this code was added because otherwise we would in swift 5 + strict-concurrency mode emit two warnings, one at the AST level and one at the SIL level. Once we are in swift-6 mode, this does not happen since we stop compiling at the AST level since we will emit the AST level diagnostic as an error.

To do this, we tried to pattern match what the AST was erroring upon and treat the parameter as disconnected instead of being isolated. Sadly, this resulted in us treating certain closure cases incorrectly and not emit a diagnostic (creating a concurrency hole).

Given that this behavior results in a bad diagnostic only to avoid emitting two diagnostics in a mode which is not going to last forever... it really doesn't make sense to keep it. We really need a better way to handle these sorts of issues. Perhaps a special semantic parameter put on the function that squelches certain errors. But that is something for another day. The specific case it messes up is:

class NonSendable {
    func action() async {}
}

@MainActor
final class Foo {
    let value = NonSendable()

    func perform() {
        Task { [value] in
            await value.action() // Should emit error but do not.
        }
    }
}

In this case, we think that value is sending... when it isnt and we should emit an error.

rdar://146378329

[gottesmm]

@swift-ci smoke test

[gottesmm]

@swift-ci smoke test

[jamieQ]

for visibility, i believe the examples in each of:

• Data race safety regression with non-sendable class in Swift 6 compiler #76003
• Data race safety bypass #76016
• Data race involving non-Sendable class may be induced when concurrently modified with task groups and actor isolation control #78360

will now produce diagnostics with this change

[gottesmm]

@swift-ci smoke test linux platform

[gottesmm]

@swift-ci test windows platform

[gottesmm]

Going to look at the linux failures in a little bit

[CrystDragon]

@jamieQ Thanks for your information, and can you help verify if this PR can solve the following simple race? (The following code definitely contains a data race, but the compiler has no problem with it at the moment)

@MainActor
func test() {
    var s = 1
    Task { @MainActor  in
        for _ in 0..<100 {
            s += 1
        }
    }
    Task.detached {
        for _ in 0..<100 {
            s += 1
        }
    }
}

[jamieQ]

can you help verify if this PR can solve the following simple race?

@CrystDragon i looked into it in the past as i know you have a outstanding issue with this scenario, and checking again now with my local compiler checkout, this patch still does not resolve that problem. IIRC from looking into it a bit in the past, the problem is that the use after send diagnostics are generated, but then they are then getting suppressed for some reason.