-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Overhaul detection of JSX attributes and tag names #47096
Conversation
@typescript-bot cherry-pick this to release-4.5 |
Heya @DanielRosenwasser, I've started to run the task to cherry-pick this into |
Hey @DanielRosenwasser, I've opened #47105 for you. |
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.
I already merged this in for TypeScript 4.5. Let's see if we can get more eyes before we actually ship on 4.5 on Monday.
src/services/completions.ts
Outdated
const kind = SymbolDisplay.getSymbolKind(typeChecker, symbol, location); | ||
if (kind === ScriptElementKind.jsxAttribute && preferences.includeCompletionsWithSnippetText && preferences.jsxAttributeCompletionStyle && preferences.jsxAttributeCompletionStyle !== "none") { | ||
if ( | ||
kind === ScriptElementKind.jsxAttribute |
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.
Why/how is kind
set to jsxAttribute
when the completion is actually a tag name? Isn’t that an issue itself, which, if fixed, would make the condition correct as previously written?
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.
When I last spoke to Jake, it seemed like this is an issue that other parts of the surrounding code handle similarly. A deeper fix might be something for a follow-up issue.
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.
I'm super AFK, but I completely agree that the right fix is to make the parser recover this differently. I was just trying to get something quick for the VS Code recovery release before I dipped out for my vacation. There's at least one other explainer comment elsewhere (some other block that is also checking that the kind is JSX attribute; I doubt I could find it from my phone!) that documents that the first attribute might be the tag name, which is why I was maybe a little less weirded out than someone looking at this PR in a vacuum.
It turns out that the parser does the right thing, it's just that for purposes of the completion, I pushed a change that adds a JSX tag name kind, however I still thing this isn't quite right as technically, the query is asking about the |
Okay, this should be more reasonable; PTAL. |
Note that this PR now includes an API change, which probably makes it not worthy of being ported to 4.5 anymore; I can likely send a PR to the 4.5 branch instead which handles the nested case without changing the "tag name completion shows as an attribute" problem. |
src/services/symbolDisplay.ts
Outdated
return ScriptElementKind.memberVariableElement; | ||
case SyntaxKind.LessThanToken: | ||
case SyntaxKind.SyntaxList: | ||
return ScriptElementKind.jsxTagName; |
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.
It would be good to test these for <Foo.Bar className="" />
and <Foo<Bar> className="" />
. Probably already ok due to different parents, but good to check for good measure.
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.
Good point. Will write some tests.
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.
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.
Your first example doesn't work with this PR, it turns out; the joy of the location
being the same for both Foo.|
and Foo.Foo |
.
The screenshot above is misleading in that I took it while the original code was there (when I was verifying that my test failed when run on the old code, but before I actually wrote the second test). I'll keep looking.
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.
Filed the above as #47416, for reference.
A lot closer, but the tooltip on the completion is wrong (says attribute), yet no snippet appears. They should not differ, as the call that determines the kind is the same one that determines that it's not a snippet completion. |
Per discussion, I'm going to split this into two PRs:
|
)" This reverts commit 1d4ec40.
Closing in favor of #47412. |
Use
contextToken
to better figure out that we're working with a JSX attribute or tag name. The location is not enough, unfortunately.Fixes #47090
Fixes #47280