This patch contains the updates for the tests. The merge removes the
`-async-main` flag, so the tests using that flag fail on that.
Additionally, the tests reflect the newer behavior of the main
resolution. `async_main_resolution` verifies that we're not preferring
an async function over a synchronous function, and vice versa.
This is also verified in `where_clause_main_resolution`, where we select
a main function using various configuration typealiases.
Finally, we only select a valid, usable main function. The old machinery
could select one sort of at random (technically it selected the first
overload declared in the source file) if an error occurred. Errors that
resulted in this behavior included a missing valid function, or an
ambiguous overload. In the case of the missing valid function, the
function returned would be from an invalid location if one existed,
which was called from `$main`. `$main` had sufficient context to realize
that the main function being called was not valid, and would emit an
error saying why. It would be better to realize that we're not getting a
valid main function earlier, and later we can emit notes saying why each
function called main could not be selected.
The async main resolution has dropped the custom availability checking,
so I am able to collapse the resolution checking into a single test
(deleting the macos-specific one).
Selection of an asynchronous main vs a synchronous main is dependent on
an `-async-main` flag. Due to the scoring mechanism, and that the
specificity of a given resolution doesn't affect the score, a more
general synchronous main will be selected over a more specific
asynchronous main when the `-async-main` flag is not passed.
If the flag is not passed and the program only contains an asynchronous
main, or the asynchronous main is the only main function that is
available given the constraints, then it will be selected.
Conversely, if the flag is set and no valid asynchronous main functions
exist, the main function will resolve to a synchronous main.
This is the same behavior that is used to resolve an synchronous and
asynchronous static function.
Fixing testing for different platforms. MacOS and iOS have
backdeployment and availability to consider. Other platforms don't need
to worry about that because they need to include the swift runtime in
the installation package anyway, so the concurrency bits can ship with
the installation.
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.
