[Sema]: ban @isolated(any) conversions to synchronous function types

[jamieQ]

currently, function conversions from @isolated(any) functions to synchronous, non-@isolated(any) functions are permitted, despite this being expressly stated as an invalid conversion in SE-0431. this change updates the type checking machinery to diagnose such conversions (currently as a warning that will be an error in a future language mode).

resolves #80823

relevant forum posts: one & two

[jamieQ]

@swift-ci please smoke test macos

[slavapestov]

Rejecting invalid conversions in the solver is generally better. For example if you have two overloads and one of the choices involves the invalid conversion, diagnosing the conversion after the solution is applied means the code will fail to type check with an ambiguity.

[jamieQ]

thanks! and just to clarify as i'm not very familiar with this area of the code – this file is part of the (constraint?) 'solver', correct?

i assume i should remove the logic from the actor isolation checker in favor of this then, since presumably there's no reason to duplicate the check in both places – or is there?

[jamieQ]

although... the comment up above does give me some pause (i don't fully grasp what it's trying to communicate):

    // Erasing global-actor isolation to non-isolation can admit data
    // races; such violations are diagnosed by the actor isolation checker.
    // We deliberately do not allow actor isolation violations to influence
    // overload resolution to preserve the property that an expression can
    // be re-checked against a different isolation context for isolation
    // violations.
    //
    // This also applies to @isolated(any) because we want to be able to
    // decide that we contextually isolated to the function's dynamic
    // isolation.

---

edit: in this instance, perhaps the concerns there don't apply, since this issue is more about a conversion that should presumably always be invalid?

[hborla]

Rejecting invalid conversions in the solver is generally better

I agree as a general principle, but we can't do that in for invalid conversions due to actor isolation, because actor isolation of context is determined after constraint solving, and that's the isolation of non-Sendable function types. Maybe this particular invalid conversion could be diagnosed in the constraint system because @isolated(any) is always part of the type, but I'm not sure that it's better to do some isolation conversion checking in the solver and the rest in the actor isolation checker.

[hborla]

And yes, like @jamieQ points out, because many invalid conversions due to isolation cannot be prevented in the constraint system, we do not allow isolation to influence overload resolution.

[xedin]

I concur with @hborla here, isolation checking is better suited here because it runs at the point where all of the moving pieces are determined and it would be easier to deal with downgrades. @jamieQ re: source compatibility I think we aught to downgrade this to a warning until future swift version unless accepting the code with this conversion is completely undesirable.

[jamieQ]

thanks all – per my understanding i should:

• move the diagnostic back into the actor isolation checker (removing it from constraint solving)
• downgrade it to a warning for source compatibility reasons

assuming that's right, i'll move this back to draft status until i can resolve those things.

[xedin]

Yep, I think that's right.

[jamieQ]

@swift-ci please smoke test

[jamieQ]

note: the proposal for Observed is currently relying on the existing behavior (see here) to be able to synchronously invoke an @isolated(any) function

[jamieQ]

@swift-ci please smoke test linux

[jamieQ]

ping { @xedin @hborla @ktoso } – when you have a chance, your feedback would be appreciated!

[jamieQ]

@swift-ci please smoke test

[jamieQ]

@swift-ci please smoke test windows

[hborla]

Thank you!

[hborla]

@jamieQ Would you mind cherry picking this fix to release/6.2?

[jamieQ]

Would you mind cherry picking this fix to release/6.2?

@hborla yep, can do