[SR-12647] Error in parsing module interface when class have the same name with the framework

[swift-ci]

Previous ID	SR-12647
Radar	None
Original Reporter	leavez (JIRA User)
Type	Bug
Status	Resolved
Resolution	Duplicate

Attachment: Download

Environment

xcode 11.4

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, ParseableInterfaces
Assignee	@beccadax
Priority	Medium

md5: 68f187714507556e295d5536bfcad851

duplicates:

• [SR-898] Unresolvable "ambiguous for type lookup" error when using multiple modules #43510

Issue Description:

The generated module interface file below will got an error when parsed by xcode.

// swift-interface-format-version: 1.0
// swift-compiler-version: Apple Swift version 5.2 (swiftlang-1103.0.32.1 clang-1103.0.32.29)
// swift-module-flags: -target x86_64-apple-ios8.0-simulator -enable-objc-interop -enable-library-evolution -swift-version 5 -enforce-exclusivity=checked -Onone -module-name A
@_exported import A
import Foundation
import Swift
@_hasMissingDesignatedInitializers public class A {
  public typealias AnotherName = A.A
  public func hi() -> A.A.AnotherName
  @objc deinit
}

("A" is the name of the framework)

Source code

public class A {
    public typealias AnotherName = A
    public func hi() -> AnotherName {
        return A()
    }
}

Steps to Reproduce

1. build a framework with the source above, with "Build Libraries for Distribution" enabled

2. delete the .swiftinterface files in the framework

3. add the generated framework to another project, import and build

Why Important

The module interface cannot be used , which means module stability never achieve its goal.

[typesanitizer]

This problem is caused due to a name collision between the module itself and the type. We have a bunch of bug reports related to this... There's a temporary workaround for this (use the -Xfrontend -module-interface-preserve-types-as-written) flag if you really need to use it but the best way forward is to rename the type to avoid the name collision with the module.

[beccadax]

This is a special case of SR-898 occurring in a module interface file. When a visible type has the same name as a module, the type shadows the module and there is currently no syntax to get around that.

Fixing this properly will require a language change like the module selectors pitch. We think it's a good idea, but we haven't found the time to do it yet.

Until we have something like that, Varun's suggested workarounds are good ones.