[PATCH] D97411: [DebugInfo] Add an attribute to force type info to be emitted for types that are required to be complete.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I expected nodebug already applied to types, even though the documentation says it only affects variables and functions. We should update the docs.

I think if we already have `nodebug` spelling, we don't need to make something general with modes. The "always emit" use case is fairly weak. It's easy to drop in a `static_assert(sizeof(Ty) > 0, "emit type info");` to get type info if you want it.

If we're looking at a no-argument attribute, my naming ideas lean towards incorporating "required [to be] complete" in the name. There are many ways that one can "use" or "require" a type that work fine with a forward declaration. Something like `emit_debug_typeinfo_if_required_complete`? Still too big? `emit_debug_if_required_complete`?



================
Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:2402-2405
+  // Don't omit definition if marked with attribute.
+  if (RD->hasAttr<ForceDebugIfRequiredTypeAttr>())
+    return false;
+
----------------
dblaikie wrote:
> Perahps this should be a bit further up in this function? For instance the template specialization homing seems like it'd override this behavior. Perhaps someone has a template specialization that shouldn't be homed for some reason? & similarly with modular debug info (both the "isDefinediInClangModule" and "hasExternalDefinitions" cases are different kinds of modular debug info homing)
> 
> Hmm, I guess the modular debug info is less likely to have these sort of problems - it's more explicit about what is homed, both explicitly making a home, and explicitly communicating the presence of a home to other compilations that rely on that data. So it might be unfortunate to pessimize that scenario unnecessarily.
> 
> @rnk - any thoughts on the tradeoff of uniformity of the attribute (ie: applies to all type homing strategies) V applying the attribute to address shortcomings in the source that only affect some homing strategies and not others?
I think it makes sense to move this up so that the user can work around extern template type homing, but we probably don't need to override module type homing behavior.

I think if we're using modular debug info, we can be pretty confident that the module will provide debug info, but it's easy to construct scenarios where the extern template is provided by a TU that doesn't enable debug info. This attribute would allow the user to work around that without going all the way to enabling fstandalone-debug, which typically generates too much data to be usable.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97411/new/

https://reviews.llvm.org/D97411