Suggest completions for type arguments of expressions #61758
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
typescript-bot
added
the
For Uncommitted Bug
|
Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page. Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up. |
mkantor
commented
May 23, 2025
src/compiler/utilities.ts
Outdated
Comment on lines
4754
to
4757
| /** @internal @knipignore */ | ||
| export function hasTypeArguments(node: Node): node is HasTypeArguments { | ||
| return !!(node as HasTypeArguments).typeArguments; | ||
| } |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
mkantor
commented
May 23, 2025
src/compiler/types.ts
Outdated
Comment on lines
1296
to
1301
| export type HasTypeArguments = | ||
| | CallExpression | ||
| | NewExpression | ||
| | TaggedTemplateExpression | ||
| | JsxOpeningElement | ||
| | JsxSelfClosingElement; |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
mkantor
force-pushed
the
completions-of-type-arguments-in-more-places
branch
from
d01431a to
e4bac38
Compare
Previously, `getTypeArgumentConstraint` could only find constraints for type arguments of generic type instantiations. Now it additionally supports type arguments of the following expression kinds: - function calls - `new` expressions - tagged templates - JSX expressions - decorators - instantiation expressions
mkantor
force-pushed
the
completions-of-type-arguments-in-more-places
branch
from
e4bac38 to
04bc7b4
Compare
|
After some consideration I removed 53d3f29 from this branch, since it's pretty tangential. If there's appetite for it I could submit another pull request. This means @typescript-bot's comment is no longer relevant. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Completions are now suggested within type arguments of the following expression types (based on type parameter constraints):
f<…>())newexpressions (new Foo<…>())tag<…>`blah`)<Component<…>/>)@decorator<…> class {})f<…>)Fixes #61751.
Limitations
:in a type argument literal) still don't happen, so No completions fromtsserverfor property values in generic type arguments #56299 should remain open.I might take a stab at this, but it'll be a separate effort from the present changeset.EDIT: I took a stab at this and have something that works, but it's stacked atop this branch so I'll see where this pull request goes before opening another one.getCompletionDataincompletions.ts). This needs fixing to fully address the specific examples in No string completions in type arguments where constrained to string literal union #52898 and No IntelliSense for generic literal types #34771. EDIT: I also have a (stacked) fix for this.This comment may also be useful reading.