[flang-commits] [flang] [flang][debug] Set scope of internal functions correctly. (PR #99531)

[Tom Eccles via flang-commits]

================
@@ -299,9 +299,29 @@ void AddDebugInfoPass::runOnOperation() {
           subprogramFlags | mlir::LLVM::DISubprogramFlags::Definition;
     }
     unsigned line = getLineFromLoc(l);
-    if (!result.second.modules.empty())
+    if (fir::isInternalProcedure(funcOp)) {
+      // For contained functions, the scope is the parent subroutine.
+      mlir::SymbolRefAttr sym = mlir::cast<mlir::SymbolRefAttr>(
+          funcOp->getAttr(fir::getHostSymbolAttrName()));
+      if (sym) {
+        if (auto func = symbolTable.lookup<mlir::func::FuncOp>(
+                sym.getLeafReference())) {
+          // FIXME: Can there be situation where we process contained function
----------------
tblah wrote:

I believe that the current lowering implementation visits (and creates a function declaration) for the parent before the contained function: https://github.com/llvm/llvm-project/blob/cc2fb58639a6b87f155e6052f5ef2bbe05d5c378/flang/lib/Lower/Bridge.cpp#L488

In MLIR, the module is just an operation with a nested region like any other operation. So I presume the order of functions inside of a module is stable (in the same way that the order of operations nested inside of a function is well defined).

However, I wonder if some current or future pass might erase and re-create functions (thereby possibly shuffling their order). Perhaps all of this could be abstracted out into a function which calls itself recursively if the parent is not yet processed. The recursion will be bounded by the level of function nesting and for the reasons outlined above won't happen at all in most cases.

https://github.com/llvm/llvm-project/pull/99531