[all-commits] [llvm/llvm-project] d26c78: [flang] handle indirect module variable use in int...

[jeanPerier via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d26c78b2ad5ed0f3384d7a3ef4b4d894f2b1be3e
      https://github.com/llvm/llvm-project/commit/d26c78b2ad5ed0f3384d7a3ef4b4d894f2b1be3e
  Author: jeanPerier <jperier at nvidia.com>
  Date:   2023-09-06 (Wed, 06 Sep 2023)

  Changed paths:
    M flang/lib/Lower/Bridge.cpp
    A flang/test/Lower/HLFIR/internal-procedures-2.f90
    M flang/test/Lower/explicit-interface-results-2.f90

  Log Message:
  -----------
  [flang] handle indirect module variable use in internal procedure (#65324)

When a module variable is referenced inside an internal procedure, but
the use statement for the module is inside the host, semantics may not
create any symbols with HostAssocDetails directly under the internal
procedure scope.
So pft::getScopeVariableList, that is called in the bridge when lowering
the internal procedure scope, failed to instantiate the module
variables. This lead to "symbol is not mapped to any IR value" compile
time errors.

This patch fixes the issue by adding the variables to the list of
"captured" global variables from the host program, so that they are
instantiated as part of the `internalProcedureBindings` in the bridge.

The rational of doing it that way instead of changing
`getScopeVariableList` is that `getScopeVariableList` would have to
import all the module variables used inside the host since it cannot
know which ones are referenced inside the internal procedure from the
semantics::Scope information. The fix in this patch only instantiates
the module variables from the host that are actually referenced inside
the internal procedure.