You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
classGen1<T> {}
classGen2<T> {}
classGen3<T, U> {}
classNonGen {}
classBase {
typealiasGeneric<T> = Gen1<T>
}
classA : Base {
typealiasGeneric<T> = Gen2<T>
// Cannot specialize a non-generic definitionletg = Generic<Int>()
}
classB : Base {
typealiasGeneric<T, U> = Gen3<T, U>
// Cannot specialize a non-generic definitionletg = Generic<Int, String>()
}
classC : Base {
classGeneric<T> {}
// Cannot specialize a non-generic definitionletg = Generic<Int>()
}
classD : Base {
typealiasGeneric = NonGen// Worksletg = Generic()
}
classE : Base {
classGeneric {}
// Worksletg = Generic()
}
The text was updated successfully, but these errors were encountered:
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.
Additional Detail from JIRA
md5: d3f8e241a513631991d4bfc40bb74e94
duplicates:
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.
The text was updated successfully, but these errors were encountered: