[PATCH] D60543: [clang] Update isDerivedFrom to support Objective-C classes 🔍

Stephane Moore via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu May 9 17:29:50 PDT 2019


stephanemoore added a comment.

I did some digging and I believe there are two approaches that we can take to extend `isDerivedFrom` to support Objective-C classes.

**Option 1: Match on Common Ancestor Declaration Type**:
Convert `isDerivedFrom` to match on the common ancestor declaration type, `NamedDecl`, and return `false` for
declaration types other than `CXXRecordDecl` and `ObjCInterfaceDecl`.

Advantages:
• Largely works in-place without requiring major changes to matchers built on top of `isDerivedFrom`.

Disadvantages:
• Allows nonsensical matchers, e.g., `functionDecl(isDerivedFrom("X"))`.

**Option 2: Convert to Polymorphic Matcher**:
Convert `isDerivedFrom` to a polymorphic matcher supporting `CXXRecordDecl` and `ObjCInterfaceDecl`.

Advantages:
• Restricts usage of `isDerivedFrom` to `CXXRecordDecl` and `ObjCInterfaceDecl`.

Disadvantages:
• Potentially requires many or all matchers using `isDerivedFrom` to refactor to adapt to the polymorphic matcher interface.

**Evaluation**
I have been going back and forth as to which approach is superior. Option 1 promotes source stability at the cost of usability while
option 2 seems to promote usability at the cost of source stability. I exported a portrayal of option 1 for consideration as it
required less invasive changes. I can see arguments supporting both approaches.

What do you think? Which of the two approaches do you think we should go with? Is there another approach that I have not thought of?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60543





More information about the cfe-commits mailing list