rjmccall added inline comments.
================ Comment at: include/clang/AST/Type.h:1148 + DK_objc_weak_lifetime, + DK_c_struct_strong_field }; ---------------- ahatanak wrote: > rjmccall wrote: > > I don't think you want to refer to the fact that the C struct specifically > > contains a __strong field here. As we add more reasons, would we create a > > new enumerator for each? What if a struct is non-trivial for multiple > > reasons? Just say that it's a non-trivial C struct. > I added an enumerator for DK_c_struct_strong_field since > CodeGenFunction::needsEHCleanup distinguishes between `__weak` and `__strong` > types. Is it not necessary to distinguish between a struct that has a > `__weak` field and a struct that has a `__strong` field but not a `__weak` > field? Oh, that's right. I... hmm. The problem is that that's really a special-case behavior, and we're designing a more general feature. If we try to handle the special case in the first patch, we'll end up trivializing the general case, and that will permeate the design in unfortunate ways. So I recommend that we *not* treat them separately right now; just emit cleanups for them unconditionally. You're still planning to add support for `__weak` properties in a follow-up patch, right? Once that's in, it will make more sense to carve out the `__strong`-only behavior as a special case. https://reviews.llvm.org/D41228 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
