Find references in importing modules for members of export =ed symbols

[Andarist]

fixes #62348

[Andarist]

tests/cases/fourslash/findAllRefsEqualExportedObjectMember1.ts
tests/cases/fourslash/findAllRefsEqualExportedObjectMember2.ts
tests/cases/fourslash/findAllRefsEqualExportedClassInstanceMember1.ts

The 3 above can't find the 1st marker at 2nd and 3rd markers. That's the opposite problem to the raised issue and I think it can be treated as such (once this one would get merged I could open a new issue about it). I think it's still worth keeping the tests here though.

[Andarist]

I'm open to suggestions how to improve some(getPropertiesOfType(getTypeOfSymbol(...)), ...) bit. I couldn't find an easier way to do this for the presented object literal (and class instance!) cases.

[Andarist]

It turns out that the added checker.resolveExternalModuleSymbol call triggered a symbol merge. And that broke this test case (tests/cases/fourslash/renameExportCrash.ts):

///<reference path="fourslash.ts" />

// @allowNonTsExtensions: true
// @Filename: Foo.js
//// let a;
//// module.exports = /**/a;
//// exports["foo"] = a;

verify.baselineRename("", { });

1. The search state had the original symbol in its allSearchSymbols (the state was created first)
2. then the symbol was merged by the added code (through resolveExternalModuleSymbol -> getCommonJsExportEquals -> cloneSymbol -> recordMergedSymbol)
3. then state.checker.getSymbolAtLocation(referenceLocation) called by getReferencesAtLocation found the merged symbol through resolveEntityName -> resolveNameHelper -> result = lookup(location.locals, name, meaning) -> getSymbol -> getMergedSymbol
4. and at the ned this includes was called with that merged symbol

So it seems this was always prone to issues with lazily-merged symbols and comparing merged symbols of both looks like a reasonable solution to me.

[typescript-bot]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate