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


================
Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:2402-2405
+  // Don't omit definition if marked with attribute.
+  if (RD->hasAttr<ForceDebugIfRequiredTypeAttr>())
+    return false;
+
----------------
akhuang wrote:
> rnk wrote:
> > 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.
> Isn't it already above the template specialization part? Or which part is 
> that?
Ah, so it is. Not sure what/how I was reading it.


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

Reply via email to