8000 fix(50750): Object type literal with string literal property in contextual typing position causes language service error on all literal type references by a-tarasyuk · Pull Request #50757 · microsoft/TypeScript · GitHub
[go: up one dir, main page]
Skip to content

fix(50750): Object type literal with string literal property in contextual typing position causes language service error on all literal type references#50757

Merged
sandersn merged 2 commits intomicrosoft:mainfrom
a-tarasyuk:fix/50750
Oct 3, 2022
Merged

Conversation

@a-tarasyuk
Copy link
Contributor
@a-tarasyuk a-tarasyuk commented Sep 13, 2022

Fixes #50750

@typescript-bot typescript-bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Sep 13, 2022
@typescript-bot typescript-bot added For Milestone Bug PRs that fix a bug with a specific milestone and removed For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Sep 13, 2022
DanielRosenwasser
DanielRosenwasser reviewed Sep 13, 2022
View reviewed changes
sandersn
sandersn requested changes Sep 23, 2022
View reviewed changes
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.

I'd like to find and augment the skip-typed-jsdoc code in services instead of checking for undefined symbols in the checker.

@DanielRosenwasser
Copy link
Member
DanielRosenwasser commented Sep 23, 2022

Hm - maybe. What about @link which really does need to semantically refer to the TS declaration?

@sandersn
Copy link
Member
sandersn commented Sep 23, 2022 •
edited
Loading

This should only apply to type-related jsdoc.

@link refers to values or types, but it's resolved in a services-only code path iirc. I don't think the binder visits it either. Actually, I don't know how (or whether) rename works on @link references in TS or JS.

Edit: Oh, it works because all the services calls to get a symbol go through getSymbolAtLocation, which has the @link/see name resolution code. I suppose that skipping type-related jsdoc references in getSymbolAtLocation might be an OK place if there isn't already code for it somewhere else.

@sandersn sandersn self-assigned this Oct 3, 2022
@sandersn sandersn merged commit 7dcf11f into microsoft:main Oct 3, 2022
DanielRosenwasser
DanielRosenwasser reviewed Oct 4, 2022
View reviewed changes
@a-tarasyuk a-tarasyuk mentioned this pull request Oct 4, 2022
Closed
@DanielRosenwasser DanielRosenwasser mentioned this pull request Oct 4, 2022
Closed
@a-tarasyuk a-tarasyuk mentioned this pull request Oct 13, 2022
Closed
@microsoft microsoft locked as resolved and limited conversation to collaborators Oct 22, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@DanielRosenwasser DanielRosenwasser DanielRosenwasser approved these changes

@sandersn sandersn sandersn approved these changes

@jakebailey jakebailey Awaiting requested review from jakebailey

Assignees

@sandersn sandersn

Labels

For Milestone Bug PRs that fix a bug with a specific milestone

Projects

PR Backlog
Archived in project

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Object type literal with string literal property in contextual typing position causes language service error on all literal type references

5 participants

@a-tarasyuk @DanielRosenwasser @sandersn @jakebailey @typescript-bot
0