-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Remove CheckMode.IsForStringLiteralArgumentCompletions
#55867
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
Remove CheckMode.IsForStringLiteralArgumentCompletions
#55867
Conversation
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
@@ -28,4 +28,5 @@ | |||
//// const shallowExpression = parse("foo|/*ts*/") | |||
//// const nestedExpression = parse({ prop: "foo|/*ts2*/" }) | |||
|
|||
verify.completions({ marker: ["ts", "ts2"], exact: ["foo|foo", "foo|bar", "foo|baz"] }); | |||
verify.completions({ marker: ["ts"], exact: ["foo", "bar", "baz", "foo|foo", "foo|bar", "foo|baz"] }); |
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 matches Ron's initial expectations from #54121 .
The other case, ideally, should provide the same completions but currently, the ones based on the contextual types and the ones based on getCandidateSignaturesForStringLiteralCompletions
work quite differently (and even more so with changes from #54121 ). I plan to close the gap between both a little bit but I'm leaving that for future PRs.
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.
Seems good to me as a cleanup; I the fewer check modes the better 😄
@typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at d1477e0. You can monitor the build here. |
Heya @DanielRosenwasser, I've started to run the diff-based top-repos suite (tsserver) on this PR at d1477e0. You can monitor the build here. Update: The results are in! |
Heya @DanielRosenwasser, I've started to run the diff-based user code test suite (tsserver) on this PR at d1477e0. You can monitor the build here. Update: The results are in! |
Heya @DanielRosenwasser, I've started to run the diff-based top-repos suite on this PR at d1477e0. You can monitor the build here. Update: The results are in! |
Heya @DanielRosenwasser, I've started to run the regular perf test suite on this PR at d1477e0. You can monitor the build here. Update: The results are in! |
Hey @DanielRosenwasser, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
@DanielRosenwasser Here are the results of running the user test suite comparing Everything looks good! |
@DanielRosenwasser Here they are:
CompilerComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
StartupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@DanielRosenwasser Here are the results of running the top-repos suite comparing Everything looks good! |
1 similar comment
@DanielRosenwasser Here are the results of running the top-repos suite comparing Everything looks good! |
It's just an internal refactor.
I initially removed this special check mode almost entirely in #53996 . It was brought up in #54121 . I managed to remove it while reviewing this PR (see here) but I concluded then that this change should be proposed as a follow up - so here it is :)