Skip to content

Avoid generating implementation signatures in ambient contexts. #19708

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

Closed
wants to merge 4 commits into from

Conversation

DanielRosenwasser
Copy link
Member

Fixes #19703

@DanielRosenwasser DanielRosenwasser requested review from aozgaa and a user November 3, 2017 07:34
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be better to just add declare interface C extends I {} above the class do avoid duplicating methods.

@@ -93,14 +93,16 @@ namespace ts.codefix {
// (eg: an abstract method or interface declaration), there is a 1-1
// correspondence of declarations and signatures.
const signatures = checker.getSignaturesOfType(type, SignatureKind.Call);
const needsImplementation = !isInAmbientContext(enclosingDeclaration);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use NodeFlags.Ambient (#17831)

@@ -119,7 +121,7 @@ namespace ts.codefix {
signatureDeclarations.push(methodDeclaration);
}
}
else {
else if (needsImplementation) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that declarations.length > signatures.length but we don't want to add an implementation?
While I'm here, TypeChecker.signatureToSignatureDeclaration has a non-nullable result. Then in signatureToMethodDeclaration it's cast to another non-nullable type. Then it's tested for existence!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that declarations.length > signatures.length but we don't want to add an implementation?

Good catch, but I don't even understand what that check is for and what it's doing. @aozgaa?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See this comment (a few lines above): https://github.com/Microsoft/TypeScript/pull/19708/files#diff-6d6034083b71c2ed75493db0fe725ec5R88.

An example (haven't checked by actual debugging) might be

class C {
     foo(x: number): void;
     foo(x: string): void;
     foo(x: number | string) { console.log(x); }
}

declare class D implements C {
}

Then I think adding foo to D would be an example.

Copy link
Contributor

@aozgaa aozgaa Nov 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this check should be inside createMethodImplementingSignatures, which will just omit the body if we are in an ambient context.

EDIT: no, we do not need an implementation signature in this case. Doh.

optional: boolean,
typeParameters: ReadonlyArray<TypeParameterDeclaration> | undefined,
parameters: ReadonlyArray<ParameterDeclaration>,
returnType: TypeNode | undefined) {
return createMethod(
/*decorators*/ undefined,
modifiers,
/*asteriskToken*/ undefined,
name,
optional ? createToken(SyntaxKind.QuestionToken) : undefined,
Copy link

@ghost ghost Nov 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's wierd to create an optional method with a body even if that's legal.
If the method is optional, though, we don't want to make it look like it must be implemented; maybe just add an // optional, delete if you don't want to implement this comment and let the user decide?

parameters,
returnType,
createStubbedMethodBody());
/*returnType*/ undefined,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might as well give them the return type from the signature, right?

Copy link
Member Author

@DanielRosenwasser DanielRosenwasser Nov 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically it's unsound to union the return types in most cases, but we could do that in a different PR.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Intersection instead? It's better that they get an error when trying to return a value from the method, than that they get an error that the class failed to implement the interface, which are always hard to read..

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intersection will be impossible to fulfill most of the time.

function foo(x: number): number;
function foo(x: string): string;
function foo(x: string | number): ??? {
  // An intersection is impossible to return
}

All I'm saying is that it's unsound to do the union, but we do allow it because it's just convenient. You're right that we should probably still do it. Just felt weird.

@DanielRosenwasser DanielRosenwasser force-pushed the quickFixImplIntAmbientContexts branch from aeeeee5 to 8a211ae Compare November 3, 2017 22:11
@mhegazy
Copy link
Contributor

mhegazy commented Nov 9, 2017

@DanielRosenwasser can you please refresh this PR and address the test failures..

@mhegazy
Copy link
Contributor

mhegazy commented Mar 29, 2018

@DanielRosenwasser can we get these in?

@typescript-bot
Copy link
Collaborator

Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it.

@RyanCavanaugh RyanCavanaugh deleted the quickFixImplIntAmbientContexts branch June 16, 2022 22:06
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.

4 participants