Early-bound named parameters not resolved?

[retailcoder]

We correctly resolve Excel.Range.Cells calls, for example:

foo = currentRow.Range.Cells(12).Value

However given named parameters:

foo = currentRow.Range.Cells(ColumnIndex:=12).Value

Selecting the ColumnIndex identifier doesn't update the status bar with the expected ColumnIndex (parameter: Long), which makes me wonder if we resolve named parameters.

We are resolving user code's named parameters (although it doesn't seem to work for recursive calls).

This isn't a high-priority bug at all, since it doesn't affect inspections or refactorings (perhaps it's exactly why we didn't bother with resolving those), however it does affect the context-sensitive reference count in the status bar, making it feel as though something isn't working as it should.

I haven't looked at the source, but it seems to me this could be a fairly easy thing to fix - likely the resolver is simply deliberately working off user declarations when resolving named parameters; if that's the case then the fix is just a matter of making it include the referenced declarations too.

[bclothier]

I've reviewed this and I think this is actually more complicated than it seems.

Consider those 3 cases:

Public Sub foo()
    Dim sht As Excel.Worksheet
    
    sht.Paste Link:=True
End Sub

Public Sub foo1()
    Sheet1.Paste Link:=True
End Sub

Public Sub foo2()
    Dim v As Variant
    Dim sht As Excel.Worksheet
    
    v = sht.Cells(ColumnIndex:=12)
End Sub

In the first case, it resolves correctly and shows as Parameter when selecting the Link

In the second case, it doesn't, showing the procedure. This might need to be fixed by TypeLib due to not knowing what Sheet1 is.

In the third case, it doesn't resolve because if you look very carefully, the .Cells() returns a Range object, and creating a ColumnIndex actually references the _Default default member of the Range object.

So I think it's more to do with the default member access than external library references.

[bclothier]

Note that the PR #3893 adds a failing unit test which is currently ignored; Identify_NamedParameter_Parameter_FromExcel_DefaultAccess that covers the third case. We also have a (currently passing) unit test for first case (Identify_NamedParameter_Parameter_FromExcel) to prove that external references are being resolved correctly. Originally I was going to fix this in the PR #3893 because it seemed similar enough but based on the finding above, I think a separate PR is best.