Fix finding references to a type when there's a module with the same name

[0101]

Fixes #14411

No questions allowed.

[0101]

Ok, looks like it's not going to be that easy :)

[0101]

The Problem

So what's happening here is, when searching for modules we report what we find to the name resolution sink. Even when the identifier could still refer to a type with the same name. And from there it's written to ItemKeyStore.

fsharp/src/Compiler/Checking/NameResolution.fs

Lines 3067 to 3071 in b0f2370

	// Otherwise modules are searched first. REVIEW: modules and types should be searched together.
	// For each module referenced by 'id', search the module as if it were an F# module and/or a .NET namespace.
	let moduleSearch ad () =
	ResolveLongIdentAsModuleOrNamespaceThen sink ResultCollectionSettings.AtMostOneResult ncenv.amap m fullyQualified nenv ad id rest isOpenDecl
	(ResolveExprLongIdentInModuleOrNamespace ncenv nenv typeNameResInfo ad)

Attempt 1

There is a comment there already suggesting that modules and types should be searched together. I tried that with the existing mechanisms - to continue the search even when we've found a module by that name. But that seems to be neither necessary nor fix the issue. Which is that once we call the sink with whatever we identified first, it stays there.

Attempt 2

Another thing I tried is to replace the module item with the type when we've found it by using CallNameResolutionSinkReplacing here:

fsharp/src/Compiler/Checking/NameResolution.fs

Line 2281 in b0f2370

CallNameResolutionSink sink (m, nenv, item, emptyTyparInst, occ, ad))

However that did have a bunch of side effects one of them being that type names got replaced by new in some tooltips. Maybe this would be feasible if we somehow narrow down the scope of what we replace...?

Attempt 3

The alternative, which is what's currently in this PR, is to suppress calling the name resolution sink from here when we're searching for module names:

fsharp/src/Compiler/Checking/NameResolution.fs

Line 2435 in b0f2370

notifyNameResolution modref id.idRange

This fixes the problem and only has 2 side effects:

1. The ordering of GetAllUsesOfAllSymbolsInFile is slightly changed in some cases. But as far as I can tell there was no specific ordering to begin with.
2. In case of invalid long identifiers, parts of them which are theoretically valid can be missing from GetAllUsesOfAllSymbolsInFile - which manifests in this test - the last occurrence of Threading is missing there. Though it still works fine in the editor:
   

So I think this is a good trade off and it doesn't require any drastic changes. It is a bit ugly though.

[psfinaki]

Mhm yeah let's see if those are the only side effects :D

[0101]

Mhm yeah let's see if those are the only side effects :D

Yeah, I should probably clarify that those are the only side effects covered by our test suite :)