fix(semantic): do not bind type/value references to value/type symbols

[DonIsaac]

Fixes #3799

Only symbols with the desired "meaning" (value/type) get resolved when binding references to symbol ids.

I also updated some code in oxc_traverse, but to be honest I'm not sure what's going on there and I'd love some input on what to do there. It seems to be used by oxc_semantic, but not completely?

References

• TSC, createNameResolver

Todo

• Emit an error if a reference is unresolved because of a meaning difference (ts error code 2749 - example)
• Type annotations should count as a type+read reference for type symbols. Maybe do this in another PR?

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[codspeed-hq]

CodSpeed Performance Report

Merging #3863 will degrade performances by 11.87%

_{Comparing don/semantic/fix/value-type-references (b23b382) with main (51e54f9)}

Summary

❌ 7 regressions
✅ 21 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	don/semantic/fix/value-type-references	Change
❌	semantic[antd.js]	199.9 ms	226.9 ms	-11.87%
❌	semantic[cal.com.tsx]	54.2 ms	56.3 ms	-3.74%
❌	semantic[checker.ts]	131.1 ms	141.6 ms	-7.42%
❌	semantic[pdf.mjs]	31.5 ms	34.2 ms	-7.64%
❌	transformer[antd.js]	338.7 ms	365.5 ms	-7.32%
❌	transformer[checker.ts]	205.6 ms	216.3 ms	-4.91%
❌	transformer[pdf.mjs]	53.8 ms	56.3 ms	-4.45%

[overlookmotel]

Thanks for putting this together @DonIsaac. A couple of responses:

1. This PR aims to resolve reference identifiers correctly depending on whether they are types or variables. I'm not sure if this is what we want to do or not. As mentioned in Incorrect reference resolve in function parameter's type #3799 (comment), maybe the best solution is not to resolve type identifier references at all. i.e. The scope tree becomes purely for variable bindings and type bindings/references are ignored.

2. If we do want to include type bindings in the scope tree, and resolve references to them, then this PR is a good way to go about it, but it's not complete. In particular, we need to figure out how to support 2 bindings with same name in the same scope (1 variable binding + 1 type binding) - example below. Also, I don't believe semantic at present visits all type identifier references, and therefore doesn't resolve them all.

type Foo = number;
const Foo = 123;
function f(foo: Foo) { // `Foo` here refers to `type Foo`
    return Foo; // `Foo` here refers to `const Foo`
}

I think before going further, we should figure out what our goal is.

[DonIsaac]

For anyone reading this PR thread, the conversation is taking place on #3799.

[Dunqing]

@Boshen and I are studying how TyepScript resolves references and what container does. We'll probably be refactoring our Scope soon. maybe we'll remove the ScopeTree, and in its place, we might have a TypesScript-like container implementation.

[Boshen]

We are studying how tsc does this. Closing for house keeping. cc @Dunqing You may want to copy over some of the tests from this PR.