Stop reassigning .valueDeclaration to avoid replacing earlier declarations with late ones

[Andarist]

cc @sandersn

fixes #60590

[DanielRosenwasser]

Was the original logic trying to preserve the somewhat-sketchy logic in the binder around which type of declaration "wins" out?

[sandersn]

It sure looks like it, but there's a separate utility function for that now: setValueDeclaration, which is more complicated*. Specifically, the kind check is only for namespaces there, which wouldn't apply to this property assignments.

I think the better fix to try is

if (symbolFlags & SymbolFlags.Value) {
  setValueDeclaration(symbol, member)
}

In other words, what the binder does in addDeclarationToSymbol.

*It also has a 3rd case for function property assignments in .d.ts files.

[Andarist]

I pushed out this change. Could you take another look?

[sandersn]

It sure looks like it, but there's a separate utility function for that now: setValueDeclaration, which is more complicated*. Specifically, the kind check is only for namespaces there, which wouldn't apply to this property assignments.

I think the better fix to try is

if (symbolFlags & SymbolFlags.Value) {
  setValueDeclaration(symbol, member)
}

In other words, what the binder does in addDeclarationToSymbol.

*It also has a 3rd case for function property assignments in .d.ts files.

[sandersn]

I noticed this after ignoring it for far too long. Would you mind merging from main before this goes in?

[Andarist]

@sandersn done

[DingJun1028]

.