[5.0][Stdlib][Overlays] Rename various classes to avoid conflicting ObjC names. #21433
Conversation
|
@swift-ci please test |
|
Build failed |
mikeash
force-pushed
the
rename-avoid-objc-conflicts-5.0
branch
from
50b9a3e to
60dd607
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@apple/swift5-branch-managers Not required for convergence. This is ABI breaking. Most of the changes are not, as Note that the corresponding lldb PR needs to be merged at the same time as this one: |
|
Let's get the change reviewed and merged to master before we do this one. |
mikeash
force-pushed
the
rename-avoid-objc-conflicts-5.0
branch
from
60dd607 to
732decc
Compare
|
@swift-ci please test |
|
This is now up to date with the changes that were merged to master. When merging this one, be sure to merge apple/swift-lldb#1162 at the same time. |
|
Build failed |
|
Build failed |
…ames. 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 swiftlang#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
rdar://problem/46646438
…mes. This avoids name conflicts between generic classes in the Swift modules of the old and new stdlibs when loaded into the same process.
mikeash
force-pushed
the
rename-avoid-objc-conflicts-5.0
branch
from
732decc to
d1b9293
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
Master seems to be holding up. Merging this one. |
Cherry-pick #21331 for
swift-5.0-branch.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