[Stdlib][Overlays] Rename various classes to avoid conflicting ObjC names. #21331
Conversation
mikeash
force-pushed
the
rename-avoid-objc-conflicts
branch
from
21af72b to
b3fbb55
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@swift-ci please test |
mikeash
force-pushed
the
rename-avoid-objc-conflicts
branch
from
b3fbb55 to
6b8f42a
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@swift-ci please test |
mikeash
force-pushed
the
rename-avoid-objc-conflicts
branch
from
6b8f42a to
d23a617
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
mikeash
force-pushed
the
rename-avoid-objc-conflicts
branch
from
d23a617 to
0a28ad3
Compare
|
@swift-ci please test |
|
Helps to push ALL of the changes made to resolve the merge.... |
|
Build failed |
|
Build failed |
|
Also helps to test with the other PR it needs, sigh. |
|
@swift-ci please test |
lib/AST/Attr.cpp
Outdated
There was a problem hiding this comment.
This is unfortunate since sometimes a regular developer can write this as @objc. Maybe we should have a flag that preserves the original spelling?
There was a problem hiding this comment.
(That can come separately.)
|
Build failed |
|
@swift-ci please test linux platform |
|
Build failed |
mikeash
force-pushed
the
rename-avoid-objc-conflicts
branch
from
0a28ad3 to
c5b2bcb
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
There was a problem hiding this comment.
This one didn't need to be renamed because it's new? (And the same for the Set one.)
There was a problem hiding this comment.
Turns out yes, but I (correctly) missed it by accident, so that's bad.
mikeash
force-pushed
the
rename-avoid-objc-conflicts
branch
from
47b11c2 to
862cdea
Compare
mikeash
force-pushed
the
rename-avoid-objc-conflicts
branch
from
862cdea to
4f0cd92
Compare
…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
branch
from
4f0cd92 to
e07e1db
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@swift-ci please test |
|
Build failed |
|
Build failed |
3 participants
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