Currently, when marshaling a dynamic AST matchers, we check for the type and value validity of matcher arguments at the same time for some matchers. For instance, when marshaling hasAttr("foo"), the argument is first type checked to ensure it's a string and then checked to see if that string can locate an attribute with that name. Similar happens for other enumeration conversions like cast kinds or unary operator kinds. If the type is correct but the value cannot be looked up, we make a best-effort attempt to find a nearby name that the user might have meant, but if one cannot be found, we throw our hands up and claim the types don't match.
This has an unfortunate behavior that when the user enters something of the correct type but a best guess cannot be located, you get confusing error messages like: Incorrect type for arg 1. (Expected = string) != (Actual = String).
This patch splits the argument check into two parts: if the types don't match, give a type diagnostic. If the type matches but the value cannot be converted, give a best guess diagnostic or a value could not be located diagnostic:
clang-query> m hasAttr("cool") 1:1: Error building matcher hasAttr. 1:9: Value not found: cool clang-query> m hasAttr("attr::cool") 1:1: Error building matcher hasAttr. 1:9: Unknown value 'attr::cool' for arg 1; did you mean 'attr::Cold'
This addresses PR47057.
If the matcher type is incorrect e.g. hasValueType(cxxRecordDecl()) I think this report "value not found: cxxRecordDecl()" or something like that - really this is a type error.
This is minor and probably not worse than "matcher != matcher" today.
But for ideal error messages we might want to give the traits more responsibility for the structure of their error conditions (e.g. changing get() to return Expected<T>)