steveire added a comment. In D101572#2730012 <https://reviews.llvm.org/D101572#2730012>, @SilensAngelusNex wrote:
> Yes, the motivation for adding these is so I can use clang-transformer to > refactor a bunch of constructor calls to call a static factory method instead. > > // Before > ns::Foo x(1); > auto y = ns::Foo(1, 2); > > // After > auto x = ns::Foo::Make(1); > auto y = ns::Foo::Make(1, 2); > > That refactor only needs `hasTypeInfo` to work on these three node types, but > for consistency's sake I'd be happy to add overloads for others as well. I > looked at the types in the results of the `grep` you posted; I think it would > make sense for `hasTypeInfo` to be able to handle the classes in the first > and third groups; do you think that would be reasonable? > > Pretty sure these should work with `hasTypeInfo`. > > - TypedefNameDecl (`getTypeSourceInfo`) > - CXXBaseSpecifier (`getTypeSourceInfo`) > - CXXCtorInitializer (`getTypeSourceInfo`) > - ObjCPropertyDecl (`getTypeSourceInfo`) > - ClassTemplateSpecializationDecl (`getTypeAsWritten`) > - CompoundLiteralExpr (`getTypeSourceInfo`) > - ExplicitCastExpr (`getTypeInfoAsWritten`) > - CXXTemporaryObjectExpr (`getTypeSourceInfo`) > - CXXUnresolvedConstructExpr (`getTypeSourceInfo`) > - TemplateArgumentLoc (`getTypeSourceInfo`) > > These could make sense, but no other matchers exist for nodes of these types: > > - VarTemplateSpecializationDecl (`getTypeAsWritten`) > - OffsetOfExpr (`getTypeSourceInfo`) > - ConvertVectorExpr (`getTypeSourceInfo`) > - VAArgExpr (`getWrittenTypeInfo`) > - CXXScalarValueInitExpr (`getTypeSourceInfo`) > > These nodes have a method with a different name, but probably still make > sense to use with `hasTypeLoc`. > > - BlockDecl (`getSignatureAsWritten`) > - CXXNewExpr (`getAllocatedTypeSourceInfo`) > > These all have a method that returns a `TypeSourceInfo*`, but seem like > they're expressing something different and shouldn't work with `hasTypeInfo`. > > - EnumDecl (`getIntegerTypeSourceInfo`) > - CXXRecordDecl (`getLambdaTypeInfo`) fails if not a lambda > - FriendDecl (`getFriendType`) > - ObjCMethodDecl (`getReturnTypeSourceInfo`) > - ObjCInterfaceDecl (`getSuperClassTInfo`) > - UnaryExprOrTypeTraitExpr (`getArgumentTypeInfo`) fails when arg is expr > instead of type Great work classifying those! Yes, I think it makes sense to implement this for the 1st and 3rd groups. It might even make sense to make the method names on the classes consistent (in a prior patch) to make the matcher implementation simpler, but I'll leave it up to you to determine what's best there. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D101572/new/ https://reviews.llvm.org/D101572 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
