Fix inlay hints crash with property access expression

[gabritto]

Fixes #2241.

We needed target: esnext to repro the crash in tests.

I think the only kinds of expressions and subexpressions that can appear as a computed property name in type nodes we produce are identifiers and property/element accesses, so I've added support for those.

[Copilot]

Pull request overview

This PR fixes a crash in the inlay hints language server feature when processing property access expressions within computed property names. The issue specifically occurred with target: esnext when using expressions like [Symbol.dispose]() in object literals.

Key Changes:

• Added handling for ast.KindPropertyAccessExpression in the inlay hints display parts visitor
• Added a test case to verify the fix and prevent regression

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
internal/ls/inlay_hints.go	Added a new case to handle PropertyAccessExpression nodes in the getInlayHintLabelParts switch statement, properly visiting the expression, adding a dot separator, and visiting the name
internal/fourslash/tests/inlayHintsUsing_test.go	Added a test case that reproduces the crash scenario using Symbol.dispose in a computed property name with target: esnext

[gabritto]

Forgot to push the baselines 🙁

[DanielRosenwasser]

I think the only kinds of expressions and subexpressions that can appear as a computed property name in type nodes we produce are identifiers and property accesses (e.g. element accesses produce a grammar error), so I've only added a new case for property access expressions, but I could be wrong.

But this still causes an inlay hint crash.

using _defer = {
	[Symbol["dispose"]]() {},
};

So I think the right thing to do is probably guard early on not providing inlay hints if the name is not a supported node type.

[gabritto]

using _defer = {
	[Symbol["dispose"]]() {},
};

How does that crash? I can't repro it with my PR.

[gabritto]

using _defer = {
	[Symbol["dispose"]]() {},
};

How does that crash? I can't repro it with my PR.

Ok, I guess we can produce element accesses too in the node builder, but pretty sure nothing else. Going to update with a test for that too.

[DanielRosenwasser]

What I mean more is that we shouldn't try to produce inlay hints in the first place for those - we should modify visitVariableLikeDeclaration, or maybe isHintableDeclaration should return false depending on the kind of decl.Name().

[gabritto]

What I mean more is that we shouldn't try to produce inlay hints in the first place for those - we should modify visitVariableLikeDeclaration, or maybe isHintableDeclaration should return false depending on the kind of decl.Name().

The function I updated only ever visits type nodes that we ourselves produce from a checker type, so modulo bugs it should only have a limited number of (well-formed) ASTs to deal with.

[DanielRosenwasser]

Oh, duh, I misunderstood, sorry.