Type inference may cause BC30455 when inferred-type variable name matches module method name

[chucker]

Version Used:

Microsoft Visual Studio Enterprise 2019 Preview
Version 16.2.0 Preview 2.0
VisualStudio.16.Preview/16.2.0-pre.2.0+29006.145
Microsoft .NET Framework
Version 4.8.03752

[..]

Visual Basic Tools   3.2.0-beta2-19303-01+c9689b7ad571762df662bec55472938d18705dca

Steps to Reproduce:

1. Create a WPF app project.
2. Open MainWindow.xaml.vb, and replace its contents with the following:

Option Strict On
Option Infer On

Class MainWindow
    Sub Foo()
        Dim dataObject As DataObject
        For Each format In dataObject.GetFormats()

        Next
    End Sub
End Class

Expected Behavior:
This code should compile as is. format should be of type System.String.

Actual Behavior:
The compiler believes format to be an invocation of the method Microsoft.VisualBasic.Strings.Format().

It gives the error:

Error | BC30455 | Argument not specified for parameter 'Expression' of 'Public Function Format(Expression As Object, [Style As String = ""]) As String'.

It also renames format to Format (note casing) for the same reason.

Workarounds:

• A different variable name works fine. For example, given the following, the compiler correctly recognizes the type, doesn't rename the variable, and doesn't show an error:

Dim dataObject As DataObject
For Each formatName In dataObject.GetFormats()

Next

• Likewise, an explicit type avoids this issue:

For Each format As String In dataObject.GetFormats()

Next

Additional notes:

In an existing project, this error only started occurring after I migrated the project to the Sdk style. The full runtime is used (<VBRuntime>default</VBRuntime>).

However, in a fresh project, the error appears immediately, suggesting this may be a toolchain regression.

[gafter]

@KathleenDollard Do you think this is a bug or by design?

[KathleenDollard]

It looks like a bug. I did not reproduce, but as described, a bug.

[gafter]

@KathleenDollard Since you are allowed to use any expression for the for-each variable, why would it not bind to an existing method as described in the bug (even if that produces the error as described)?

[KathleenDollard]

@gafter So, you believe this is not a bug, just an unexpected behavior?

[gafter]

@KathleenDollard I think it might be.

[chucker]

Two notes:

• the behavior has apparently changed somewhere between VB Tools 2.10 and 3.2. Given the toolchain from VS 2017, I cannot reproduce the above behavior:

Microsoft Visual Studio Enterprise 2017 
Version 15.9.14
VisualStudio.15.Release/15.9.14+28307.770
Microsoft .NET Framework
Version 4.8.03752

[..]

Visual Basic Tools   2.10.0-beta2-63501-03+b9fb1610c87cccc8ceb74a770dba261a58e39c4a

• to my knowledge, I cannot opt out of globally importing the Microsoft.VisualBasic namespace (it's imported with the Sdk). This effectively makes Format a reserved keyword of sorts.

[KathleenDollard]

Based just on @chucker's explanation, we need to look into this as a regression. If I understand the description, and the "bind to a method" theory is correct, this would make a number of things act like keywords that didn't before.

[jaredpar]

Moving to the SDK. As mentioned in the bug this is about the forced import of Microsoft.VisualBasic namespace in the SDK. There is nothing the compiler can do about this.

[KathleenDollard]

Has the Microsoft.VisualBasic namespace ever been optional in Visual Basic?

[dsplaisted]

It looks like the implicit imports can be disabled with the DisableImplicitNamespaceImports property.

[sfoslund]

PR #3723 confirmed that this is solved by disabling implicit imports with the DisableImplicitNamespaceImports