This saves us from having to do overload resolution on the overlay module, which fails if an overlay declaration exactly matches the imported signature of the original ObjC declaration. Fixes rdar://problem/42352695 harder.
The overlay may add overloads for UIApplicationMain for various reasons. When we generate the special `main` implementation for a `@UIApplicationMain` class, we want to call the original function from Objective-C, so pick that one where there are multiple overloads to choose from. Fixes rdar://problem/42352695.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
If a source file contains the main class for its module, then implicitly emit a top_level_code that invokes UIApplicationMain with the name of the marked class.
Swift SVN r18088
