This is an archive of the discontinued LLVM Phabricator instance.

Improve dynamic AST matching diagnostics for conversion errors
ClosedPublic

Authored by aaron.ballman on Aug 9 2020, 8:29 AM.

Details

Summary

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.

Diff Detail

Event Timeline

aaron.ballman requested review of this revision.Aug 9 2020, 8:29 AM
aaron.ballman created this revision.

Ping

Ping x2

I realize it's performance review time for some folks and their schedules may be busier than usual, gently pinging this so it doesn't fall through the cracks.

sammccall accepted this revision.Sep 18 2020, 7:47 AM

Sorry about the delay, good guess as to what was happening :-)

clang/lib/ASTMatchers/Dynamic/Marshallers.h
88

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>)

This revision is now accepted and ready to land.Sep 18 2020, 7:47 AM
aaron.ballman closed this revision.Sep 23 2020, 9:14 AM

Thank you for the review. I've commit in 819ff6b945816dce144c8be577a3c245f702b59c

clang/lib/ASTMatchers/Dynamic/Marshallers.h
88

That's a good idea for a future change!