Fix resolving entity name of namespace member after alias is merged with type

[andrewbranch]

Fixes #51975. The root cause of the bug is essentially the same as the ones described in #50455.

[jakebailey]

Can this be simplified to just calling resolveSymbol in the original symbol = ... expression RHS above?

I feel like I fixed a bug like this recently that did something similar. That and there's getExportSymbolOfValueSymbolIfExported which I think is related and does some of this chain of calls. (I think we're somewhat inconsistent about it.)

[andrewbranch]

No, because then we would fail to look up the property on the original value of namespace, which could very well be the one that has the export—it’s just not in this case. You could make a (somewhat more contrived) test where the alias points to a type and the local declaration is the namespace containing the export we’re looking for.

[weswigham]

I think this also needs another condition, like

Suggested change

	symbol = getMergedSymbol(getSymbol(getExportsOfSymbol(resolveAlias(namespace)), right.escapedText, meaning));
	if (!getMergedSymbol(getSymbol(getExportsOfSymbol(namespace), right.escapedText, SymbolFlags.All))) {
	symbol = getMergedSymbol(getSymbol(getExportsOfSymbol(resolveAlias(namespace)), right.escapedText, meaning));
	}

since if that symbol exists in the original non-alias namespace (just with not the target meanings we're looking for), it should probably still block lookup in the alias target... right?

[andrewbranch]

I’m not sure it should, but it’s worth noting that this scenario you describe would be a merge error. In the test given, the non-alias symbol meaning is the type alias Something<A>—not a namespace at all. If we change it to be a namespace and try to reason about which of the two namespaces we want to pull from:

[weswigham]

Are you sure you can't manage a similar shape in JS that we don't technically error on though? Something like

// @Filename: usage.ts
import { Something } from "./prelude"
export const myValue: Something<string> = Something.of("abc")
export type MyType = Something.SubType<string>

// @Filename: Something.ts
export type Something<A> = { value: A }
export type SubType<A> = { value: A }
export declare function of<A>(value: A): Something<A>

// @Filename: prelude.js
import * as S from "./Something"
export * as Something from "./Something"
export type Something<A> = S.Something<A>;
module.exports.Something = 12;

[andrewbranch]

In that example, we basically seem to ignore the module.exports.Something assignment, both before and after this change. But just imagine that the double-namespace example I gave was not an error, and our emit did something that would make the runtime merge work as expected. If that were possible, then the following would be true:

1. Exports declared in multiple locations of that merged namespace would need to be checked for mergeability the same way local namespace merges are checked, so duplicate values/types couldn’t clobber each other.
2. If two declarations of the same-named export are allowed to merge, since one is a type and one is a value, I don’t see why the local one should block the alias one.

Saying that the local should block the alias would be predicated on the runtime merge not working, but there’s already a top-level error for that.

[weswigham]

Yeah, I guess that's true; JS merges already let weird things with totally undefined behavior happen anyway, so it's not really important how they influence this.