This is an archive of the discontinued LLVM Phabricator instance.

[ASTMatchers][Dynamic] Provide Fallback and suggestions for typos.
Needs ReviewPublic

Authored by njames93 on Mar 4 2021, 8:59 AM.

Details

Summary

If there is a typo in parsing and we can see a close match, offer a suggestion hint and in the case of matchers carry on parsing to see if more diags are generated.

Diff Detail

Event Timeline

njames93 created this revision.Mar 4 2021, 8:59 AM
njames93 requested review of this revision.Mar 4 2021, 8:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 4 2021, 8:59 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Tests haven't been added yet, wanted to gauge opinions on this first before fully committing to it.

clang/lib/ASTMatchers/Dynamic/TypoSuggester.cpp
40

Duly noted :)

njames93 updated this revision to Diff 328664.Mar 5 2021, 3:12 PM

Address clang-tidy issue.

njames93 added inline comments.Mar 5 2021, 3:23 PM
clang/include/clang/ASTMatchers/Dynamic/Diagnostics.h
62–72

Any reason for these being explicitly initialized?

I like the idea, but I think you're violating the Interface Segregation Principle by putting it in the Registry::lookupMatcherCtor implementation. The interface here is easy to use incorrectly. Consider adding a new method instead. That way, lookupMatcherCtor will continue to do what it's name says it does and it will never return a "wrong" matcher. A new lookupCloseMatch API can be called if the optional returned by lookupMatcherCtor is None. That seems to be a more consistent API.