Hello,<br><br>I have sent the two patches with the full precomputation of the index during compilation.<br><br>I'll standardize the existing diagnostics in another patch to differentiate a functional patch from a stylistic one.<br>
<br>Also, I did not implement the fuzzy matching yet, mainly because the index is still unused, and so I would not be able to test it. I just wanted to create the index in this patch to avoid later modifications to tblgen (since it implies modifying llvm and providing two linked patches).<br>
<br>I would recommend using StringRef::edit_distance for the fuzzy match, since it's what is used for auto completion. However the names are "bare" C-Strings... would it be okay to StringRef-ize the Diagnostic interface ? Or perhaps only StringRef-ize the internals and still return C-Strings ?<br>
<br>Matthieu<br><br><br><div class="gmail_quote">2011/4/13 Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com">kyrtzidis@apple.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Matthieu, I really like your suggestions for improving diagnostics!<br>
<div class="im"><br>
On Mar 19, 2011, at 11:12 AM, Matthieu Monrocq wrote:<br>
<br>
><br>
> 2. I have added an Index to map the name of the diagnostic back to the ID. For efficient search this index is sorted... on first use. I could not find a way to get the TableGen backend to sort it by itself because the diagnostics are splitted over multiple files. Because it is sorted only on first use, I don't expect any impact (apart from the memory it takes) during a regular run, since it should only be invoked through the help menu. Also, even if sorting is "relatively" expensive (< 2k elements), since it's for the help, I guess it does not matter too much.<br>

<br>
</div>.td files can include other .td files. You could add a new .td file aggregating all the diagnostics so you can have TableGen produce the necessary sorted arrays.<br>
<div class="im"><br>
><br>
> I just have one little issue: what if I don't find it ? At the moment I hijacked diag::DIAG_UPPER_LIMIT for signaling an invalid name. Is this correct ?<br>
><br>
> I was also thinking that we could probably propose a fuzzy match for a best effort search, in case we didn't locate the name, because users may make a typo when invoking the help.<br>
<br>
</div>Proposing a match if one was not found is a good idea.<br>
<div class="im"><br>
> I would suggest adding a boolean parameter to indicate whether the call wishes for this extended search or not. Thoughts ?<br>
<br>
</div>Why not always propose a match ?<br>
<div class="im"><br>
><br>
> 3. I have had some troubles extracting names from the IDs. Most IDs are well-behaved and begin by `fatal_`, `err_`, `ext_`, `warn_` or `note_` but there's a couple that do not (beginning by `error_` or embedding the `warn` in the middle of the string or just not indicating anything of the sort). For those, I simply print the whole ID as the name, however I'd like to provide a clean-up (separate) patch to "standardize" them.<br>

<br>
</div>Please "standardize" them.<br>
<br>
-Argiris<br>
</blockquote></div><br>