Skip to content
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

Open
ankitspd opened this issue Jan 12, 2018 · 8 comments
Open
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@ankitspd
Copy link
Member

Previous ID SR-6747
Radar rdar://problem/36559620
Original Reporter @aciidb0mb3r
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee None
Priority Medium

md5: 23c5ee100e792faafa92e529f5017220

Issue Description:

public class Product: Codable {

    public let name: String

    init(name: String) {
        self.name = name
    }

    public final class Executable: Product {

        public let targets: [String]

        init(name: String, targets: [String]) {
            self.targets = targets
            super.init(name: name)
        }

        private enum CodingKeys: CodingKey {
            case targets
        }

        public required init(from decoder: Decoder) throws {
            let values = try decoder.container(keyedBy: CodingKeys.self)
            self.targets = try values.decode([String].self, forKey: .targets)
            try super.init(from: decoder)
        }

        public override func encode(to encoder: Encoder) throws {
            var container = encoder.container(keyedBy: CodingKeys.self)
            try container.encode(targets, forKey: .targets)
            try super.encode(to: encoder)
        }
    }
}
Compile Swift Module 'codable' (1 sources)
/private/tmp/codable/Sources/codable/main.swift:23:57: error: ambiguous reference to member 'CodingKeys'
            let values = try decoder.container(keyedBy: CodingKeys.self)
                                                        ^~~~~~~~~~
/private/tmp/codable/Sources/codable/main.swift:18:22: note: found this candidate
        private enum CodingKeys: CodingKey {
                     ^
<unknown>:0: note: found this candidate
/private/tmp/codable/Sources/codable/main.swift:29:56: error: ambiguous reference to member 'CodingKeys'
            var container = encoder.container(keyedBy: CodingKeys.self)
                                                       ^~~~~~~~~~
/private/tmp/codable/Sources/codable/main.swift:18:22: note: found this candidate
        private enum CodingKeys: CodingKey {
                     ^
<unknown>:0: note: found this candidate
error: terminated(1): /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2017-12-30-a.xctoolchain/usr/bin/swift-build-tool -f /private/tmp/codable/.build/debug.yaml main

It works if I rename the enum to something else.

@belkadan
Copy link
Contributor

@itaiferber, you had one of these already, right?

@itaiferber
Copy link
Contributor

Not this specific issue, I don't think. Holding on to this one.

@itaiferber
Copy link
Contributor

@swift-ci Create

@itaiferber
Copy link
Contributor

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.

@itaiferber
Copy link
Contributor

@belkadan Who would be the most appropriate person to forward this to? I passed the Radar itself along to you for further triaging.

@belkadan
Copy link
Contributor

Thanks for the reduction! I sent the Radar over to the type checker folks, so I'll just tag this bug as TypeChecker.

@rudkx
Copy link
Member

rudkx commented Mar 1, 2018

@DougGregor, it seems like we should treat the inner definition of MyEnum as shadowing the outer one, but aren't. Do you have a dup or other issues this one should be related to?

@DougGregor
Copy link
Member

I agree that we should treat the inner definition of `MyEnum` as shadowing. I don't think I have a dupe for this one.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

5 participants