[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