[Runtime][Stdlib][Overlays] Rename various Objective-C classes and methods to avoid conflicts. #19295
Conversation
…thods that would conflict when loading old Swift libraries into a process alongside ABI-stable libraries. rdar://problem/35768222
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
Do you think it might be useful to use something besides an additional |
|
I'm torn between the desire to more clearly distinguish between old and new, and the desire to keep things short and simple for what will soon be the common case of only having the new stuff loaded. I don't want some |
|
Maybe it would be sufficient to note somewhere near the |
|
That definitely sounds like a wise idea to me. |
|
(I'm just checking to see if this will pass PR testing, I'll be sure to add those comments before I actually merge.) |
…xplaining the rename and noting that the old name cannot be used due to conflicts. rdar://problem/35768222
|
Build failed |
|
Build failed |
|
apple/swift-lldb#911 @swift-ci please test OS X platform |
|
Build failed |
|
apple/swift-lldb#911 @swift-ci please test OS X platform |
…classes-and-methods
|
@swift-ci please test |
|
Build failed |
|
Build failed |
mikeash
force-pushed
the
rename-conflicting-classes-and-methods
branch
from
526c79f to
1fb165a
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
…classes-and-methods
|
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
…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
These classes and methods would conflict when loading old Swift libraries into a process alongside ABI-stable libraries.
rdar://problem/35768222