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-10563] Shadowing Base Class Generic With Another Generic Type Causes Compile Error #52963

Closed
swift-ci opened this issue Apr 26, 2019 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-10563
Radar None
Original Reporter trevorthoele (JIRA User)
Type Bug
Status Resolved
Resolution Duplicate
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: d3f8e241a513631991d4bfc40bb74e94

duplicates:

  • SR-3492 Unexpected inheritance of nested types

Issue Description:

Introducing a new name into a derived class that shadows a base class' generic with its own generic causes the compile error "Cannot specialize a non-generic definition".

Below are some combinations.

class Gen1<T> {}


class Gen2<T> {}


class Gen3<T, U> {}


class NonGen {}


class Base {
    typealias Generic<T> = Gen1<T>
}


class A : Base {
    typealias Generic<T> = Gen2<T>
    
    // Cannot specialize a non-generic definition
    let g = Generic<Int>()
}


class B : Base {
    typealias Generic<T, U> = Gen3<T, U>
    
    // Cannot specialize a non-generic definition
    let g = Generic<Int, String>()
}


class C : Base {
    class Generic<T> {}
    
    // Cannot specialize a non-generic definition
    let g = Generic<Int>()
}


class D : Base {
    typealias Generic = NonGen
    
    // Works
    let g = Generic()
}


class E : Base {
    class Generic {}
    
    // Works
    let g = Generic()
}
@belkadan
Copy link
Contributor

@slavapestov, @DougGregor, any idea what's going on here?

@slavapestov
Copy link
Member

Expression pre-checking only converts a SpecializeExpr of an UnresolvedDeclRefExpr into a TypeExpr if the name lookup produces one result. When there are multiple results, we continue on to type check the overloaded expression. However the modeling of SpecializeExpr is pretty busted for generic type aliases. Even when it does work it sometimes gets the substitutions wrong. We should fix it at some point, but for now your best bet is to not overload types by name at all.

@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
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

3 participants