Compiler shouldn't allow a closure capturing `isolated` parameter to be marked `@concurrent` or `@MainActor`

[rayx]

Description

Compiler currently doesn't allow a function taking isolated parameter to be marked @concurrent or @MainActor, but it allows a closure capturing isolated parameter to do that. While the implementation appears to work well (see SIL below), it's quite misleading, especially when the closure is defined within an actor and captures self by calling methods or accessing properties.

Also, the behaviors of the two examples appears inconsistent. See table below.

	isolation specified by modifier	isolation specified by isolation parameter	where does fn1 runs?
example 1	global executor	MainActor	MainActor
example 2	MyGlobalActor	MainActor	MyGlobalActor

Example 1) @concurrent + isolated parameter

SIL: https://swift.godbolt.org/z/qhKTWvWv3

func foo(_ isolation: isolated MainActor) async {
    let c: @concurrent () async -> Void = { 
        fn1()
        _ = isolation; 
        await fn2() 
    }

    await bar(isolation, c)
}

func bar(_ isolation: isolated MainActor, _ fp: @concurrent () async -> Void) async {
    await fp()
}

func fn1() {}

@MainActor 
func fn2() {}

Below are what happen in closure c, based on its SIL:

• hop to MainActor
• call fn1
• hop to MainActor
• call fn2
• hop (back) to MainActor and return

Example 2) @MainActor + isolated parameter

SIL: https://swift.godbolt.org/z/c7MGfEzqn

@globalActor
actor MyGlobalActor {
    static let shared = MyGlobalActor()
}

func foo(_ isolation: isolated MainActor) async {
    let c: @MyGlobalActor () async -> Void = { 
        fn1()
        _ = isolation; 
        await fn2() 
    }

    await bar(isolation, c)
}

func bar(_ isolation: isolated MainActor, _ fp: @MyGlobalActor () async -> Void) async {
    await fp()
}

func fn1() {}

@MainActor 
func fn2() {}

Below are what happen in closure c, based on its SIL:

• hop to MyGlobalActor
• call fn1
• hop to MainActor
• call fn2
• hop back to MyGlobalActor and return

Reproduction

See above examples

Expected behavior

They shouldn't compile

Environment

Swift 6.2 and beyond (nightly, etc.)

Additional information

1. I suspect this may also cause weird RBI issues.
2. I also suspect Converting nonisolated(nonsending) closure to @concurrent closure may cause data race #87674 might be related to this issue, but I don't have more details yet.

[jamieQ]

I think this should compile, but the implementation may actually be incorrect in these cases, or at least it violates my mental model of how it's supposed to work. IIUC if you make a closure that is actor-isolated and convert it to a @concurrent function type (which I believe is essentially what's happening here), that should basically be equivalent to its being wrapped in a thunk that hops off the actor before running wherever the closure was originally supposed to execute. In these examples, it does not look to me like that is what happens – the @concurrent annotation appears to do nothing (at least in terms of the runtime behavior), which seems wrong.

[xedin]

This looks like some SIL shenanigans, coming out of Sema the type of c is a @concurrent function.