Skip to content

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

Conversation

HerrCai0907
Copy link
Member

@HerrCai0907 HerrCai0907 commented Aug 19, 2022

fix: #2447 and #2446

  • I've read the contributing guidelines
  • I've added my name and email to the NOTICE file

@HerrCai0907 HerrCai0907 requested a review from MaxGraey August 19, 2022 03:50
@MaxGraey MaxGraey changed the title fix: fix resolveNamedType cannot resolve type parameter in contextual element fix: Fix resolveNamedType cannot resolve type parameter in contextual element Aug 19, 2022
src/resolver.ts Outdated
Comment on lines 193 to 197
type = assert(ctxTypes.get(simpleName));
} else {
type = ctxElement.lookupGenericType(simpleName);
}
if (type) {
Copy link
Member

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.

Copy link
Member Author

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);
Copy link
Member

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?

Copy link
Member Author

@HerrCai0907 HerrCai0907 Aug 20, 2022

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.

@HerrCai0907
Copy link
Member Author

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 T in class F will pass through contextualTypeArguments and cause error.

@dcodeIO
Copy link
Member

dcodeIO commented Aug 21, 2022

I think I see now. Can you add a comment along the lines of...?

// Default parameters are resolved in context of the called function, not the calling function

@MaxGraey MaxGraey merged commit b044b71 into AssemblyScript:main Aug 21, 2022
@MaxGraey
Copy link
Member

Thanks!

@HerrCai0907 HerrCai0907 deleted the fix/resolve-default-type-in-generic-method branch August 21, 2022 02:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Generic parameters with default values loose external context
3 participants