[cfe-dev] cfe-dev Digest, Vol 45, Issue 19

[Matthieu Monrocq]

Hello,

I have sent the two patches with the full precomputation of the index during
compilation.

I'll standardize the existing diagnostics in another patch to differentiate
a functional patch from a stylistic one.

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

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 ?

Matthieu


2011/4/13 Argyrios Kyrtzidis <kyrtzidis at apple.com>

> Hi Matthieu, I really like your suggestions for improving diagnostics!
>
> On Mar 19, 2011, at 11:12 AM, Matthieu Monrocq wrote:
>
> >
> > 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.
>
> .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.
>
> >
> > 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 ?
> >
> > 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.
>
> Proposing a match if one was not found is a good idea.
>
> > I would suggest adding a boolean parameter to indicate whether the call
> wishes for this extended search or not. Thoughts ?
>
> Why not always propose a match ?
>
> >
> > 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.
>
> Please "standardize" them.
>
> -Argiris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110415/67edeaf5/attachment.html>