[Bug]: vbnet: cross-file and VB -> C# calls produce no calls edges (Module functions, typed locals, C# statics) #4570

Activity

1. TerraVenil

   added

   bugSomething isn't workingSomething isn't working

   on Oct 19, 2026
2. github-actions commented on Oct 19, 2026

   

   github-actionsBot

   on Oct 19, 2026 – with GitHub Actions

   More actions

   Thanks for opening this issue, @TerraVenil. A maintainer will take a look soon.

   If you would like to discuss it in real time, come say hi on our Discord server. For longer-form questions and ideas there is also GitHub Discussions.

   To help us triage, please make sure the report includes what you expected, what actually happened, and the steps (and a small sample) to reproduce it.
3. Deepjyoti-Sarmah commented on Oct 19, 2026

   

   Deepjyoti-Sarmah

   on Oct 19, 2026

   Contributor

   More actions

   Reproduced on v8 (0.9.92).

   The cause is in extractors/vbnet.py. For each call, the extractor looks up the type that owns the target, but it only knows the types declared in the same file. If the owner is a Module in another file, a local variable or a C# type, the extractor drops the call, so no cross-file resolver ever sees it. The only VB resolver, resolve_vbnet_partial_calls, handles Partial types. The shared name pass skips VB calls because they are marked as member calls. An unqualified LogIt("x") does get through, but with the caller's own type as owner, so the resolver looks for Caller.LogIt and finds nothing.

   My first repro was missing Helpers.vb, so case G looked broken. With the file present, G works on v8, as you said.

   I checked each lookup rule against the VB compiler (dotnet SDK 8.0) before writing the fix:

   Case	Compiler binds to
   unqualified call to a Module in another file, same namespace	the Module
   Module in another namespace, no Imports	error BC30451
   the same with Imports, or with the Module in an enclosing namespace	the Module
   the caller's class or its base class has a LogIt	the class method, at any arity
   two Modules declare LogIt, even with different arities	error BC30562
   a field, property or nested type with the same name	that member, not the Module
   Dim w As New Worker(), As Worker = New Worker(), Dim w = New Worker()	Worker.Save
   CsRules.IsLocked(1) or csrules.islocked(1) from VB	the C# method
   .Save() inside With w	w.Save, not the caller's Save
   handler(1) where handler is a local Action(Of Integer)	the delegate, not a handler method

   v8 gets the last two rows wrong. It binds both calls to the caller's own method of the same name.

   The fix adds a VB resolver that follows these rules. It makes an edge only when exactly one target matches, and it never falls back to a name match across the corpus. A class whose base is outside the corpus, such as Inherits System.Windows.Forms.Form, still gets its Module calls, marked INFERRED because the base could declare the same name.

   Not covered:

   • receivers typed by a field;
   • With block targets;
   • project-level Imports and RootNamespace from the .vbproj.

   Two separate bugs turned up:

   • the C# member resolver ignores arity when calling an overloaded VB Module;
   • nested VB types are not extracted at all.

   PR to follow.