Switch to the inheritance-based visitor from the lambda-based visitor to
allow both preorder and postorder customizations during type
transformation. NFC intended.
Details
- Reviewers
ahatanak erik.pilkington - Commits
- rG78b84cf99120: [ObjC] For type substitution in generics use a regular recursive type visitor.
rC354180: [ObjC] For type substitution in generics use a regular recursive type visitor.
rL354180: [ObjC] For type substitution in generics use a regular recursive type visitor.
Diff Detail
- Build Status
Buildable 27285 Build 27284: arc lint + arc unit
Event Timeline
clang/lib/AST/Type.cpp | ||
---|---|---|
1295 | Does this works with type sugar? i.e. previously calling Ty->getAs<ObjCObjectType>() would have stripped through TypedefType, but its not obvious to me that this traversal is doing the right thing for that case. |
clang/lib/AST/Type.cpp | ||
---|---|---|
1295 | You are right, great catch. And I have a test case to confirm that. I've started this refactoring to avoid copy-pasting QualType modifiedType = recurse(T->getModifiedType()); if (modifiedType.isNull()) return {}; QualType equivalentType = recurse(T->getEquivalentType()); if (equivalentType.isNull()) return {}; if (modifiedType.getAsOpaquePtr() == T->getModifiedType().getAsOpaquePtr() && equivalentType.getAsOpaquePtr() == T->getEquivalentType().getAsOpaquePtr()) return QualType(T, 0); and use BaseType::VisitAttributedType(attrType) instead. I think it is possible to achieve the previous behaviour with the traditional recursive visitor. But ideas that I have are pretty complicated and I don't think that's the right trade-off. |
I've added a test case with typedef and think it should be emitting a warning. I.e., the behaviour with typedef should be the same as without it, modulo different pretty-printing in diagnostic. The interesting part is that this test is failing even without my change. I'll look into that and depending on the fix, I'll update this change accordingly.
clang/lib/AST/Type.cpp | ||
---|---|---|
1295 | The test case I've added isn't really testing regressions in this refactoring, it uncovers already broken functionality. After some investigation turns out there is no simple test case that would be passing before this change and failing afterwards. It is so because we were going past type sugar only in stripObjCKindOfType which is called from sameObjCTypeArgs to compare type args and type args are canonicalized during construction, so there is no type sugar. We also have stripObjCKindOfTypeAndQuals which has different implementation. My next step is to have a separate fix for TypedefTypeParam. |
Does this works with type sugar? i.e. previously calling Ty->getAs<ObjCObjectType>() would have stripped through TypedefType, but its not obvious to me that this traversal is doing the right thing for that case.