|
|
| Previous ID |
SR-898 |
| Radar |
rdar://problem/19481048 |
| Original Reporter |
mkadijk (JIRA User) |
| Type |
Bug |
Environment
Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81) / Xcode Version 7.2.1 (7C1002) / iOS 9.2
Additional Detail from JIRA
|
|
| Votes |
18 |
| Component/s |
Compiler |
| Labels |
Bug |
| Assignee |
None |
| Priority |
Medium |
md5: ea3a4fb46f14a67b99d4cb07142d5803
blocks:
- SR-14195 Swift emits an invalid module interface when a public type has the same name as a module
Issue Description:
Given two modules with the same type, where one module has a type that has the same name as the module itself with generic parameters it will become impossible to explicitly refer to the type you want.
Example
Module A:
struct NoError: ErrorType {}
Module B:
struct B<T> {}
struct NoError: ErrorType {}
The app:
import A
import B
let ambiguousError: NoError // This correctly errors because it's ambiguous
let errorA: A.NoError // This correctly works since we make the module explicit
let errorB: B.NoError // This _incorrectly_ errors, complaining about required arguments
Expected behaviour
Only ambiguousError should give an error, the other two error constants should work since the module is specified to prevent ambiguous type errors.
What happend instead
The error we get with B.NoError is Reference to generic type 'B' requires arguments in <...>. The compiler incorrectly assumes we are referring to struct B instead of the module B. This makes it impossible to fix the ambiguity.
Workaround
It is possible to work around this by creating a typealias in a seperate file where we only import module B and there typealias BNoError = NoError then we can use the BNoError as the type of let errorB to work around the issue.
Environment
Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81) / Xcode Version 7.2.1 (7C1002) / iOS 9.2
Additional Detail from JIRA
md5: ea3a4fb46f14a67b99d4cb07142d5803
blocks:
Issue Description:
Given two modules with the same type, where one module has a type that has the same name as the module itself with generic parameters it will become impossible to explicitly refer to the type you want.
Example
Module A:
Module B:
The app:
Expected behaviour
Only
ambiguousErrorshould give an error, the other two error constants should work since the module is specified to prevent ambiguous type errors.What happend instead
The error we get with
B.NoErrorisReference to generic type 'B' requires arguments in <...>. The compiler incorrectly assumes we are referring tostruct Binstead of the module B. This makes it impossible to fix the ambiguity.Workaround
It is possible to work around this by creating a
typealiasin a seperate file where we only import module B and theretypealias BNoError = NoErrorthen we can use theBNoErroras the type oflet errorBto work around the issue.