-
-
Notifications
You must be signed in to change notification settings - Fork 673
fix: Fix resolveNamedType cannot resolve type parameter in contextual element #2448
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
fix: Fix resolveNamedType cannot resolve type parameter in contextual element #2448
Conversation
src/resolver.ts
Outdated
type = assert(ctxTypes.get(simpleName)); | ||
} else { | ||
type = ctxElement.lookupGenericType(simpleName); | ||
} | ||
if (type) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like there is a foregoing issue, as ctxTypes
should have all the types. Is there perhaps something missing instead where ctxTypes
is populated? Like, right now, lookupGenericType
does after-the-fact what should already have been done before it seems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we just need to find a position to sync generic type in ctxElement
to ctxType
when ctxElement
is Function
or Class
.
src/resolver.ts
Outdated
@@ -763,7 +768,7 @@ export class Resolver extends DiagnosticEmitter { | |||
} | |||
let defaultType = typeParameterNode.defaultType; | |||
if (defaultType) { | |||
let resolvedDefaultType = this.resolveType(defaultType, ctxFlow.actualFunction, contextualTypeArguments, reportMode); | |||
let resolvedDefaultType = this.resolveType(defaultType, prototype, contextualTypeArguments, reportMode); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is somewhat similar. The actualFunction
should be an instance of prototype
, then sharing state, or is it different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actualFunction is caller side context. But inferring default type, it need callee side context.
class F<T> {
foo(a: StaticArray<string>): string[] {
const result = a.slice(0);
// push some things onto "result"
return result;
}
}
export function foo(a: StaticArray<string>): string[] {
let f = new F<f64>();
return f.foo(a)
} consider this case. In old version, generic |
I think I see now. Can you add a comment along the lines of...?
|
Thanks! |
fix: #2447 and #2446