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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang/include/clang/Basic/Attr.td:1665
+  let Spellings = [Clang<"force_debug_if_required_type">];
+  let Subjects = SubjectList<[CXXRecord]>;
+  let Documentation = [Undocumented];
----------------
dblaikie wrote:
> akhuang wrote:
> > dblaikie wrote:
> > > aaron.ballman wrote:
> > > > Does this attribute have effect in C? If so, this should be `Record` instead of `CXXRecord`. If not, should this get a `LangOpts` field so the attribute is explicitly unused in C?
> > > Seems (at least based on some limited testing I just did) we don't do type homing in C at all, even the basic "is the type required to be complete" sort of thing, like this:
> > > ```
> > > struct s { int i; };
> > > struct s *g;
> > > ```
> > > compiled as C, that produces a definition of `s`, compiled as C++ it produces a declaration of `s`
> > > 
> > > (& because I was curious - we don't home enums under these rules (we handle enums differently anyway - because sometimes they're used as bags of constants, so we have to preserve their definition even when they're not referenced through the usual function/variable type links, etc))
> > Yep, there's a check for `LangOpts.CPlusPlus` before the debug optimizations.
> > 
> > Maybe should change it to `Record` anyway, even though it does nothing in C at the moment.
> I'd probably keep it to C++ if that's the only place it works, so people aren't confused if they put it in C code but it does nothing yet produces no error about misuse.
> 
> (only tradeoff there, is if the type is in a C header, meant for use from C and C++ - the attribute would have to be conditional on whether the code is being parsed as C++ - but that seems OK to me)
> I'd probably keep it to C++ if that's the only place it works, so people aren't confused if they put it in C code but it does nothing yet produces no error about misuse.

+1 -- it's easy for us to lift the restriction if/when C support appears.

> (only tradeoff there, is if the type is in a C header, meant for use from C and C++ - the attribute would have to be conditional on whether the code is being parsed as C++ - but that seems OK to me)

I think that's defensible behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97411