Fix getDefinitionAtPosition to return correct kind for each merged declaration

[PaulyBearCoding]

Fixes #22467

Problem

When multiple declarations share the same name (merged declarations), getDefinitionAtPosition() returns incorrect kind values for non-class declarations.

Current behavior:
Given merged declarations (namespace, class, interface), all three return kind: "class"

Expected behavior:
Each declaration should return its actual kind:

• Namespace declaration: kind: "module"
• Class declaration: kind: "class"
• Interface declaration: kind: "interface"

Reproduction

Test Code

namespace A {
    export interface B {}
}
class A {}
interface A {}

var x: A;  // getDefinitionAtPosition on 'A' here

Steps to Reproduce Bug (Without Fix)

1. Created test file with merged declarations
2. Built TypeScript compiler from pristine main branch
3. Called languageService.getDefinitionAtPosition() on reference to A
4. Retrieved kind property from each returned definition

Result:

Definition 1 (namespace A): kind: "class"     ← WRONG
Definition 2 (class A):     kind: "class"     ✓ correct
Definition 3 (interface A): kind: "class"     ← WRONG

All three definitions report kind: "class" instead of their individual kinds.

Root Cause

In src/services/goToDefinition.ts, the function uses SymbolDisplay.getSymbolKind() which checks combined symbol flags:

// src/services/symbolDisplay.ts:118-137
export function getSymbolKind(typeChecker: TypeChecker, symbol: Symbol, location: Node): ScriptElementKind {
    const flags = getCombinedLocalAndExportSymbolFlags(symbol);  // Combined flags
    if (flags & SymbolFlags.Class) {
        return ScriptElementKind.classElement;  // Returns here for merged declarations
    }
    if (flags & SymbolFlags.Interface) return ScriptElementKind.interfaceElement;
    if (flags & SymbolFlags.Module) return ScriptElementKind.moduleElement;
    // ...
}

For merged declarations with flags SymbolFlags.Class | SymbolFlags.Interface | SymbolFlags.Module:

• First condition flags & SymbolFlags.Class evaluates to true
• Function returns ScriptElementKind.classElement immediately
• Never checks Interface or Module flags
• All declarations receive the same kind value

Solution

Check each declaration's individual SyntaxKind instead of combined symbol flags.

Added getKindFromDeclaration() function:

function getKindFromDeclaration(declaration: Declaration, checker: TypeChecker, symbol: Symbol, node: Node): ScriptElementKind {
    switch (declaration.kind) {
        case SyntaxKind.ClassDeclaration:
            return ScriptElementKind.classElement;
        case SyntaxKind.ClassExpression:
            return ScriptElementKind.localClassElement;
        case SyntaxKind.InterfaceDeclaration:
            return ScriptElementKind.interfaceElement;
        case SyntaxKind.ModuleDeclaration:
            return ScriptElementKind.moduleElement;
        case SyntaxKind.EnumDeclaration:
            return ScriptElementKind.enumElement;
        case SyntaxKind.TypeAliasDeclaration:
            return ScriptElementKind.typeElement;
        default:
            return SymbolDisplay.getSymbolKind(checker, symbol, node);
    }
}

Updated call site in createDefinitionInfo():

// Before:
kind: SymbolDisplay.getSymbolKind(typeChecker, symbol, location)

// After:
kind: getKindFromDeclaration(declaration, typeChecker, symbol, location)

Verification

Test Without Fix (CONTRIBUTING.md Requirement)

Per CONTRIBUTING.md: "At least one test should fail in the absence of your non-test code changes."

Procedure:

1. Saved baseline with fix applied
2. Stashed fix from src/services/goToDefinition.ts
3. Rebuilt TypeScript without fix
4. Ran test: npx hereby runtests --tests=goToDefinitionMergedDeclarations
5. Test failed with exit code 1 (baseline mismatch)
6. Saved baseline without fix
7. Created diff
8. Restored fix

Result:

14c14
< "kind": "class",        ← WITHOUT fix (namespace)
---
> "kind": "module",       ← WITH fix (namespace)
34c34
< "kind": "class",        ← WITHOUT fix (interface)
---
> "kind": "interface",    ← WITH fix (interface)

Test creates incorrect baseline (all "class") without the fix.
Test creates correct baseline (proper kinds) with the fix.

Test With Fix

Built TypeScript with fix applied.
Ran test: npx hereby runtests --tests=goToDefinitionMergedDeclarations

Result:

1 passing (235ms)

All definitions return correct kinds:

• Namespace declaration: kind: "module"
• Class declaration: kind: "class"
• Interface declaration: kind: "interface"

Full Test Suite

Ran complete test suite: npx hereby runtests-parallel

Result:

98,956 passing
0 failing

Linting: PASSED (0 errors, 0 warnings)

Baseline Updates

The fix corrected kind values in 4 additional test baselines where declarations were previously misreported:

1. goToDefinitionThis.baseline.jsonc

   • Class in constructor context
   • Before: kind: "parameter"
   • After: kind: "class"

2. goToDefinitionTypeofThis.baseline.jsonc

   • Class in typeof context
   • Before: kind: "parameter"
   • After: kind: "class"

3. goToTypeDefinition4.baseline.jsonc

   • Type alias merged with const
   • Before: kind: "const"
   • After: kind: "type"

4. goToTypeDefinition_arrayType.baseline.jsonc

   • Built-in Array interface
   • Before: kind: "var"
   • After: kind: "interface"

All baseline changes represent bug fixes, not regressions.

Performance Testing

Tested performance impact on getDefinitionAtPosition() API.

Test configuration:

• 74,000 API calls across 4 test cases
• 1,000 iterations per case (100 warmup)
• Merged and non-merged declarations

Results:

Metric	Baseline (without fix)	Fixed (with fix)	Delta
Total time	13,513ms	11,877ms	-1,636ms (-12.1%)
Avg per call	0.183ms	0.160ms	-0.023ms (-12.1%)
Throughput	5,476 calls/sec	6,231 calls/sec	+755 calls/sec (+13.8%)

Fix improves performance by 12.1% due to simplified code path:

• Before: Get symbol → Combine flags → Check multiple bitwise conditions → Return
• After: Check declaration SyntaxKind → Switch statement (O(1) jump table) → Return

Files Changed

Modified (5 files):

• src/services/goToDefinition.ts - Added getKindFromDeclaration() function
• tests/baselines/reference/goToDefinitionThis.baseline.jsonc
• tests/baselines/reference/goToDefinitionTypeofThis.baseline.jsonc
• tests/baselines/reference/goToTypeDefinition4.baseline.jsonc
• tests/baselines/reference/goToTypeDefinition_arrayType.baseline.jsonc

New (2 files):

• tests/cases/fourslash/goToDefinitionMergedDeclarations.ts - Test case
• tests/baselines/reference/goToDefinitionMergedDeclarations.baseline.jsonc - Expected output

Testing Summary

• Test fails without fix (exit code 1, wrong baseline created)
• Test passes with fix (1 passing, correct kinds returned)
• Full test suite passes (98,956 passing, 0 failing)
• Linting passes (0 errors, 0 warnings)
• Performance improves (12.1% faster)
• All baselines verified as bug fixes

Note on Implementation Approach

Issue comment suggested using getMeaningFromLocation and hasMatchingMeaning for filtering definitions. This PR addresses the kind reporting issue (ensuring each declaration returns its correct kind) rather than filtering which definitions to return. The two approaches serve different purposes and could potentially complement each other.

[PaulyBearCoding]

@microsoft-github-policy-service agree

[PaulyBearCoding]

Hi! I noticed the PR is failing on Node 14 Windows, but passing on all other platforms and Node versions (16, 18, 20, 22, 24). The test also passes locally on my machine (Node 24/Linux).

Is the Node 14 Windows test known to be flaky? Node 14 reached EOL in April 2023.

Details:

• ✅ All other tests passing (25+ checks)
• ✅ Test passes locally
• ❌ Only failing: Node 14 on Windows
• Code change: Simple switch statement with no Node 14-specific syntax

Should I investigate further, or is this a known issue with the CI environment?

[jakebailey]

Just a slow test run on the slowest runners on GHA with the slowest node version, unfortunately

[PaulyBearCoding]

Ah, the triple threat: old Node, Windows, and slow hardware! 😄 Thanks for the heads up – I was worried I'd broken something spectacular. Appreciate the quick response!