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.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
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 :) |
clang/include/clang/ASTMatchers/Dynamic/Diagnostics.h | ||
---|---|---|
62–72 | Any reason for these being explicitly initialized? |
Comment Actions
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.
Any reason for these being explicitly initialized?