[SR-14153] -module-interface-preserve-types-as-written still qualifies types for synthesized extensions

[05262b81-54a9-4fe1-bf6a-96f8042de10e]

Previous ID	SR-14153
Radar	rdar://problem/73985900
Original Reporter	@lilyball
Type	Bug

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.

[typesanitizer]

@swift-ci create