Environment
Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
Target: x86_64-apple-darwin19.6.0
Additional Detail from JIRA
| | |
|------------------|-----------------|
|Votes | 0 |
|Component/s | Compiler |
|Labels | Bug |
|Assignee | None |
|Priority | Medium |
md5: 49dd829d00b59bb7dd0edc9525dda429
Issue Description:
If I have code that gets a synthesized extension, such as
enum Foo: String {
case one, two
}
and I compile with -Xfrontend module-interface-preserve-types-as-written, the synthesized extensions still qualify the type with the module name:
// swift-interface-format-version: 1.0
// swift-compiler-version: Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
// swift-module-flags: -target x86_64-apple-macosx10.10 -enable-objc-interop -enable-library-evolution -swift-version 5 -O -module-name Module
public enum Foo : String {
case one, two
public typealias RawValue = Swift.String
public init?(rawValue: Swift.String)
public var rawValue: Swift.String {
get
}
}
extension SameName.Foo : Swift.Equatable {}
extension SameName.Foo : Swift.Hashable {}
extension SameName.Foo : Swift.RawRepresentable {}
Not just the extensions, but also the synthesized members of Foo use qualified names such as Swift.String, though that's a lot less likely to be a problem.
This causes issues when trying to use -module-interface-preserve-types-as-written to work around a name collision issue as documented in SR-14142.
Environment
Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28) Target: x86_64-apple-darwin19.6.0Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: 49dd829d00b59bb7dd0edc9525dda429Issue Description:
If I have code that gets a synthesized extension, such as
and I compile with
-Xfrontend module-interface-preserve-types-as-written
, the synthesized extensions still qualify the type with the module name:Not just the extensions, but also the synthesized members of
Foo
use qualified names such asSwift.String
, though that's a lot less likely to be a problem.This causes issues when trying to use
-module-interface-preserve-types-as-written
to work around a name collision issue as documented in SR-14142.