New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-6747] error: ambiguous reference to member 'CodingKeys' when subclassing #49296
Comments
@itaiferber, you had one of these already, right? |
Not this specific issue, I don't think. Holding on to this one. |
@swift-ci Create |
Looks like this actually isn't directly related to Codable. Managed to pare this down to protocol P {}
func printPType<T : P>(_ type: T.Type) {
print(type)
}
class Foo {
private enum MyEnum : P {}
class Bar : Foo {
private enum MyEnum : P {}
func bar() {
printPType(MyEnum.self)
}
}
} which produces NestedError.swift:14:24: error: ambiguous reference to member 'MyEnum'
printPType(MyEnum.self)
^~~~~~
NestedError.swift:11:22: note: found this candidate
private enum MyEnum : P {}
^
NestedError.swift:8:18: note: found this candidate
private enum MyEnum : P {}
^ Looks like passing the private type to a generic function accepting the type based on a protocol constraint fails in the constraint solver. More info is in the Radar. |
@belkadan Who would be the most appropriate person to forward this to? I passed the Radar itself along to you for further triaging. |
Thanks for the reduction! I sent the Radar over to the type checker folks, so I'll just tag this bug as TypeChecker. |
@DougGregor, it seems like we should treat the inner definition of |
I agree that we should treat the inner definition of `MyEnum` as shadowing. I don't think I have a dupe for this one. |
Additional Detail from JIRA
md5: 23c5ee100e792faafa92e529f5017220
Issue Description:
It works if I rename the enum to something else.
The text was updated successfully, but these errors were encountered: