In https://bugs.llvm.org/show_bug.cgi?id=37006 Nico Weber points out a
flaw in OptTable::findNearest: if an option "foo"'s prefixes are "--"
and "-", then the nearest option for "--fob" will be "-foo". This is
incorrect, however, since the function is expected to return "--foo".
The bug is due to a naive loop that attempts to predetermines which
prefix is best. Instead, compute the edit distance for each prefix/name
pair.
Test Plan: check-llvm
Shouldn't getting the longest prefix here be good enough? Something like this:
StringRef Prefix; int PrefixLength = 0; for (int P = 0; Candidateinfo.Prefixes[P]; P++) { StringRef Candidate = CandidateInfo.Prefixes[P]; if (Candiate.size() > PrefixLength && Option.startswith(Candidate)) { Prefix = Candidate; PrefixLength = Candidate.size(); } }…and keep everything else the same?