Skip to content

Don't include completions for current and later parameters #52690

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

Merged

Conversation

zardoy
Copy link
Contributor

@zardoy zardoy commented Feb 9, 2023

Tried to find oldest completion issue :)

Fixes #1858

@typescript-bot typescript-bot added the For Backlog Bug PRs that fix a backlog bug label Feb 9, 2023
@zardoy zardoy changed the title add impl to ensure its not lost Don't include completion for self-referencing and next parameters Feb 9, 2023
Copy link
Member

@DanielRosenwasser DanielRosenwasser left a comment

Choose a reason for hiding this comment

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

The test file should be renamed:

tests/cases/fourslash/noIncorrectParamaterCompletions.ts
tests/cases/fourslash/noCompletionsForCurrentOrLaterParameters.ts

Comment on lines 2052 to 2053
const variableDeclaration = getVariableDeclaration(location);
const parameterDeclaration = getParameterDeclaration(contextToken);
Copy link
Member

Choose a reason for hiding this comment

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

Can you just switch the helper function to just be getVariableOrParameterDeclaration and make decisions based on that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So your decision is to unify variableDeclaration and parameterDeclaration?

eg

const variableOrParameterDeclaration = getVariableOrParameterDeclaration(location, contextToken)

But what about this case then?:

const foo = (a = foo/*no foo suggestion*/) => {
    console.log(foo)
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

BTW its fully valid location for foo suggestion, so maybe you're right

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I switched to getVariableOrParameterDeclaration(contextToken: Node | undefined). I'm using only contextToken to fit logic in single findAncestor. I don't really the idea of dropping location as I feel it can introduce a lot of breakage, though I'll look at tests and try to fix them

Copy link
Contributor Author

Choose a reason for hiding this comment

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

BTW its fully valid location for foo suggestion, so maybe you're right

FYI

Comment on lines 2131 to 2142
// Filter out parameters from their own initializers
// `function f(a = /* no 'a' here */) { }`
if (symbol.valueDeclaration === parameterDeclaration) {
return false;
}
// Filter out parameters from other parameters' initializers
// `function f(a = /* no 'b' here */, b) { }`
const parameters = parameterDeclaration.parent.parameters;
const currentParamIdx = parameters.indexOf(parameterDeclaration);
if (parameters.slice(currentParamIdx).some((p) => symbol.valueDeclaration === p)) {
return false;
}
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if you could just get await with using the node positions.

Suggested change
// Filter out parameters from their own initializers
// `function f(a = /* no 'a' here */) { }`
if (symbol.valueDeclaration === parameterDeclaration) {
return false;
}
// Filter out parameters from other parameters' initializers
// `function f(a = /* no 'b' here */, b) { }`
const parameters = parameterDeclaration.parent.parameters;
const currentParamIdx = parameters.indexOf(parameterDeclaration);
if (parameters.slice(currentParamIdx).some((p) => symbol.valueDeclaration === p)) {
return false;
}
const declarationPos = symbol.valueDeclaration.pos;
if (parameterDeclaration.pos <= declarationPos && declarationPos < parameters.end) {
return false;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Seems to be good idea! but I still wonder why do we need declarationPos < parameters.end check?

@zardoy zardoy changed the title Don't include completion for self-referencing and next parameters Don't include completions for current and later parameters Feb 9, 2023
@zardoy
Copy link
Contributor Author

zardoy commented Feb 9, 2023

Didn't expect so many failing tests 😅 , will look again at them in a few days

though it was enough to do most top contextToken only, but lets be consistent in code
@zardoy
Copy link
Contributor Author

zardoy commented Feb 9, 2023

It seems using contextToken in new implementation improved quality in some test cases, I'm happy with result

@zardoy
Copy link
Contributor Author

zardoy commented Feb 9, 2023

Also I have a quick question. Speaking of getVariableOrParameterDeclaration I wonder wether the logic can be extracted for codefixes in future. Just for motivation consider this issue:

let fileName

const foo = (displayName = fileNam/*<-*/, fileName2) => {
    // ERROR: Cannot find name 'fileNam'. Did you mean 'fileName2'?

    // super annoying sometimes, would be cool if codefixes were smarter
}

@zardoy
Copy link
Contributor Author

zardoy commented Feb 17, 2023

@DanielRosenwasser I'm sorry to bother you, but I wanted to do the same for type parameters. Would it be better to do it in this PR or create another one after its get merged? Its just a matter of adding an extra check 😉.

@jakebailey
Copy link
Member

I'm sorry to bother you, but I wanted to do the same for type parameters. Would it be better to do it in this PR or create another one after its get merged? Its just a matter of adding an extra check 😉.

How simple are we talking? If it's not too bad, I don't think it's a big deal to include it here.

@zardoy
Copy link
Contributor Author

zardoy commented Feb 19, 2023

How simple are we talking? If it's not too bad, I don't think it's a big deal to include it here.

Okay, I think it's done

Copy link
Member

@sandersn sandersn left a comment

Choose a reason for hiding this comment

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

Very nice and small change. I had some questions and suggestions.

@sandersn sandersn self-assigned this Mar 9, 2023
@zardoy
Copy link
Contributor Author

zardoy commented Mar 20, 2023

I see it's in waiting on author. Is anything else required here from my side?

@sandersn
Copy link
Member

I was waiting on a review from @DanielRosenwasser since he previously requested changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Backlog Bug PRs that fix a backlog bug
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Only prior declared parameters should appear in completion lists for initializers
5 participants