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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
