You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The typesystem was avoiding the async main function if any synchronous
main was available. This is because the decl contexts where the main
function is looked up from aren't async contexts (extension contexts,
generic type contexts), so if a synchronous main function exists
anywhere, it will be a better "fit" for the context.
Since we're the main function, we decide on whether or not we want to be
async, so looking at the decl-context's asyncness is really the wrong
thing to do. Plumbing this info through the constraint system seems
risky at best, catastrophic at worst, so instead, I'm just grabbing the
buffer of resolved decls and doing my own scoring and selection.
We want to ensure that we are picking the main function that is closest
to the decl marked with `@main` in the protocol conformance chain. This
means that if your `@main` struct directly conforms to a protocol that
implements a main function, you should probably use it. If that protocol
implements two main functions, one sync and one async, we look at
whether we support async before selecting it.
Things get a little bit weird if you have implemented an async main in
the closest protocol, but are targeting something that doesn't support
concurrency. The `@available` checking should handle this with a nice
error saying you're doing bad things, but if you circumvent that
checking for bad reasons, it will still fall back on a synchronous main
function if one is available.
// CHECK-IS-ERROR: error: 'MyMain' is annotated with @main and must provide a main static function of type () -> Void or () throws -> Void
89
+
90
+
// CHECK-IS-ERROR-ASYNC: error: 'MyMain' is annotated with @main and must provide a main static function of type () -> Void, () throws -> Void, () async -> Void, or () async throws -> Void
0 commit comments