Old Swift and new Swift runtimes and overlays need to coexist in the same process. This means there must not be any classes which have the same ObjC runtime name in old and new, because the ObjC runtime doesn't like name collisions.
When possible without breaking source compatibility, classes were renamed in Swift, which results in a different ObjC name.
Public classes were renamed only on the ObjC side using the @_objcRuntimeName attribute.
This is similar to the work done in pull request #19295. That only renamed @objc classes. This renames all of the others, since even pure Swift classes still get an ObjC name.
rdar://problem/46646438
They're all the same anyway, and no longer even need to be compiled,
just copied in as text.
And drastically simplify how we "generate" them. Instead of attaching
their build jobs to the appropriate overlays, if present, "just" have
one job to copy them all and attach it to the Darwin overlay. That's
what we do for the overlay shim headers, and it's good enough.
(Eventually we want to get out of the business of shipping them
altogether.)
This does have the same flaw as the shim headers: if you /just/ change
API notes, the corresponding overlay does not get rebuilt. You have to
touch that too. But in practice that'll happen most of the time
anyway.
Part of rdar://problem/43545560
This refactoring uses large portions of the already existing code for
x86_64 and s390 to implement AAPCS64 __VaListBuilder. The parts where
each implementation differ are the x86_64 header, and the order of the
general and vector registers.
The changes also addresses many of the request from the reviewers in
#20862 which were not addressed originally, like the reuse of the
already existing code, and the generalizations for the code to be useful
for platforms different than Linux (Android, for example).
Colocate the target specific library specification. Inline the single
site use of the place holder ICU_UC and ICU_I18N libraries rather than
trying to create special library processing code for that.
This constant is needed for SHFileOperation which is needed for
Foundation. Unfortunately, it is a complex macro which will not be
imported by the ClangImporter.
This commit supersedes 2866b4a which was overwritten by 4ab45df.
Store small string code units in little-endian byte order. This way
the code units are in the same order on all machines and can be
safely treated as an array of bytes.
