[PATCH] D101572: Make `hasTypeLoc` matcher support nodes of type `CXXFunctionalCastExpr` and `CXXTemporaryObjectExpr`.

[Stephen Kelly via Phabricator via cfe-commits]

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