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

David Blaikie via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Feb 25 10:19:10 PST 2021


dblaikie 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];
----------------
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)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97411



More information about the cfe-commits mailing list