-gmodules: Don't emit incomplete breadcrumbs pointing to nonexistant PCM files.

[aprantl]

Summary

When a module name is specified as -fmodule-name, that module gets a
clang::Module object, but it won't actually be built or imported; it
will be textual. CGDebugInfo wouldn't detect this and them emit a
DICompileUnit that had a hash but no name and that confused both
dsymutil, LLDB, and myself.

rdar://problem/47926508

[JDevlieghere]

This makes sense to me, just one nit.

lib/CodeGen/CGDebugInfo.cpp

2304

Maybe it's just me but I had to reread this sentence a few times to be sure what you meant by the double negation. Maybe clang module without ASTFile must be specified by -fmodule-name is easier to grok.

[dblaikie]

This, I guess, is part of the impact of moving towards explicit modules (-fmodule-name is for building a module with that name, right?)?

With explicit modules there is the option for modular code generation - which doesn't require any specific DWARF consumer support (so should "just work" - if you've a build system you can teach to generate a .o file from the .pcm, and link that .o with everything else)

[aprantl]

In D57976#1393939, @dblaikie wrote:

This, I guess, is part of the impact of moving towards explicit modules (-fmodule-name is for building a module with that name, right?)?

That option is overloaded. It's used to specify the name of an explicit modules too, but in this context particularly it is used to specify that clang is compiling the Framework that defines the module with that name, which has the effect of *not* building the module of that name as a clang module even though -fmodules was specified and every other module is built as a module. This is necessary for developing Frameworks that are part of the macOS SDK to avoid accidentally include the module from the OS instead of the one being developed. That's a quite specific use-case.

With explicit modules there is the option for modular code generation - which doesn't require any specific DWARF consumer support (so should "just work" - if you've a build system you can teach to generate a .o file from the .pcm, and link that .o with everything else)

Different can of worms, I believe.

[dblaikie]

In D57976#1393976, @aprantl wrote:

In D57976#1393939, @dblaikie wrote:

This, I guess, is part of the impact of moving towards explicit modules (-fmodule-name is for building a module with that name, right?)?

That option is overloaded. It's used to specify the name of an explicit modules too, but in this context particularly it is used to specify that clang is compiling the Framework that defines the module with that name, which has the effect of *not* building the module of that name as a clang module even though -fmodules was specified and every other module is built as a module. This is necessary for developing Frameworks that are part of the macOS SDK to avoid accidentally include the module from the OS instead of the one being developed. That's a quite specific use-case.

With explicit modules there is the option for modular code generation - which doesn't require any specific DWARF consumer support (so should "just work" - if you've a build system you can teach to generate a .o file from the .pcm, and link that .o with everything else)

Different can of worms, I believe.

Ah, fair enough - thanks for the context!

lib/CodeGen/CGDebugInfo.cpp

for (auto &M : PPOpts.Macros) {
         default:
           OS << c;
         }
       OS << '\"';
     }
   }
 
   bool IsRootModule = M ? !M->Parent : true;
-  if (CreateSkeletonCU && IsRootModule) {
+  // When a module name is specified as -fmodule-name, that module gets a
+  // clang::Module object, but it won't actually be built or imported; it will
+  // be textual.
+  if (CreateSkeletonCU && IsRootModule && Mod.getASTFile().empty())
+    assert((!M || (M->Name == CGM.getLangOpts().ModuleName)) &&
+           "clang module without ASTFile was not specified by -fmodule-name");
+
+  if (CreateSkeletonCU && IsRootModule && !Mod.getASTFile().empty()) {
     // PCH files don't have a signature field in the control block,
     // but LLVM detects skeleton CUs by looking for a non-zero DWO id.
     // We use the lower 64 bits for debug info.
     uint64_t Signature =
         Mod.getSignature()
             ? (uint64_t)Mod.getSignature()[1] << 32 | Mod.getSignature()[0]
             : ~1ULL;
     llvm::DIBuilder DIB(CGM.getModule());
     DIB.createCompileUnit(TheCU->getSourceLanguage(),
                           // TODO: Support "Source" from external AST providers?
                           DIB.createFile(Mod.getModuleName(), Mod.getPath()),
                           TheCU->getProducer(), true, StringRef(), 0,
                           Mod.getASTFile(), llvm::DICompileUnit::FullDebug,
                           Signature);
     DIB.finalize();
   }
+
   llvm::DIModule *Parent =
       IsRootModule ? nullptr
                    : getOrCreateModuleRef(
                          ExternalASTSource::ASTSourceDescriptor(*M->Parent),
                          CreateSkeletonCU);
   llvm::DIModule *DIMod =
       DBuilder.createModule(Parent, Mod.getModuleName(), ConfigMacros,
                             Mod.getPath(), CGM.getHeaderSearchOpts().Sysroot);

test/Modules/DebugInfo-fmodule-name.c

+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fmodule-format=obj -fmodule-name=F \
+// RUN:     -debug-info-kind=limited -dwarf-ext-refs \
+// RUN:     -fimplicit-module-maps -x c -fmodules-cache-path=%t -F %S/Inputs \
+// RUN:     %s -S -emit-llvm -debugger-tuning=lldb -o - | FileCheck %s
+
+#include "F/F.h"
+
+// CHECK: !DICompileUnit
+// CHECK-NOT: dwoId:
+
+// We still want the import, but no skeleton CU, since no PCM was built.
+
+// CHECK: !DIModule({{.*}}, name: "F"
+// CHECK-NOT: !DICompileUnit
+// CHECK-NOT: dwoId: