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

Jump to bottom

[SR-12281] Name resolution of shadowed nested types no longer disambiguates #54709

Closed
ChristopherRogers opened this issue Feb 27, 2020 · 2 comments
Closed

[SR-12281] Name resolution of shadowed nested types no longer disambiguates #54709

ChristopherRogers opened this issue Feb 27, 2020 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@ChristopherRogers
Copy link
Contributor

Previous ID SR-12281
Radar rdar://problem/59830281
Original Reporter @ChristopherRogers
Type Bug
Status Resolved
Resolution Duplicate
Environment

Swift 5.2 (both Xcode 11.4 beta 2 and 2020-02-23 dev toolchains)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: ac3fbd3ed2f30ea89ec7a06e83f06d6f

duplicates:

  • SR-12137 Swift 5.2 regression with nested classes

Issue Description:

The following code compiles in Swift 5.1 but fails in 5.2. I'm not sure if the compiler was supposed to allow this before, so I'm filing a bug to make sure.

class Parent {
    enum Inner {
        static let constantP = "P"
    }
}

class Child: Parent {
    enum Inner {
        static let constantC = "C"
    }

    static func foo() {
        print(Inner.constantC) // OK
        print(Inner.constantP) // Type 'Child.Inner' has no member 'constantP'
        print(Parent.Inner.constantP) // OK
    }
}
@hborla
Copy link
Member

hborla commented Feb 27, 2020

@swift-ci create

@slavapestov
Copy link
Member

The original behavior would look in every superclass for a nested type of that name, but it would also diagnose an ambiguity if multiple such nested types defined the same member. See https://bugs.swift.org/browse/SR-3492.

My fix for that problem was perhaps too heavy-handed; we still search the superclass chain for the nested type, but a nested type in a subclass now shadows a nested type with the same name defined in a superclass.

I'm not sure if its worth tweaking this behavior further at this point; in any case, I'm going to dupe the bug to https://bugs.swift.org/browse/SR-12137 and ping some core team members there to decide what the best course of action is.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ChristopherRogers @slavapestov @hborla