[PATCH] D58152: [Sema] Delay checking whether objc_designated_initializer is being applied to an init method

Erik Pilkington via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Feb 13 11:47:27 PST 2019


erik.pilkington added inline comments.


================
Comment at: clang/lib/Sema/SemaDeclAttr.cpp:7258-7267
+  // Do this check after processing D's attributes because the attribute
+  // objc_method_family can change whether the given method is in the init
+  // family, and it can be applied after objc_designated_initializer. This is a
+  // bit of a hack, but we need it to be compatible with versions of clang that
+  // processed the attribute list in the wrong order.
+  if (D->hasAttr<ObjCDesignatedInitializerAttr>() &&
+      cast<ObjCMethodDecl>(D)->getMethodFamily() != OMF_init) {
----------------
aaron.ballman wrote:
> Do you also have to handle redeclaration merging, or is that not a thing for ObjC method declarations?
> 
> I'm wondering if this is better handled with the `mergeFooAttr()` pattern from `Sema::mergeDeclAttribute()`?
You mean delaying the check until we see the method implementation? It seems like that would only enable the following:

```
@interface X
-(instancetype)meth __attribute__((objc_designated_initializer));
@end
@implementation X
-(instancetype)meth __attribute__((objc_method_family(init))) {}
@end
```

We never supported this, so there isn't any regression here. I don't even think that this makes sense, the `objc_method_family` attribute should really go in the @interface. It also means that we'd only diagnose this in the TU that contains the `@implementation`.


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

https://reviews.llvm.org/D58152





More information about the cfe-commits mailing list