[cfe-dev] Ranges for diagnostics

[Milian Wolff]

On Friday 24 January 2014 08:25:26 David Blaikie wrote:
> On Fri, Jan 24, 2014 at 6:26 AM, Milian Wolff <mail at milianw.de> wrote:
> > Hey there,
> > 
> > integrating clang into KDevelop we noticed that some diagnostics are
> > lacking
> > ranges which are in our opinion useful to have. Take this example:
> > 
> > ~~~~~~~
> > class foobar {};
> > class foobar {};
> > 
> > void foo(double);
> > void foo(float);
> > 
> > int main()
> > {
> > 
> >   foo(0);
> >   
> >   "123" + 1;
> >   return 0;
> > 
> > }
> > ~~~~~~~
> > 
> > If you compile this with clang++ you'll get:
> > 
> > ~~~~~~~
> > test.cpp:2:7: error: redefinition of 'foobar'
> > class foobar {};
> > 
> >       ^
> > 
> > test.cpp:1:7: note: previous definition is here
> > class foobar {};
> > 
> >       ^
> > 
> > test.cpp:9:3: error: call to 'foo' is ambiguous
> > 
> >   foo(0);
> >   ^~~
> > 
> > test.cpp:4:6: note: candidate function
> > void foo(double);
> > 
> >      ^
> > 
> > test.cpp:5:6: note: candidate function
> > void foo(float);
> > 
> >      ^
> > 
> > test.cpp:11:9: warning: expression result unused [-Wunused-value]
> > 
> >   "123" + 1;
> >   ~~~~~ ^ ~
> > 
> > 1 warning and 2 errors generated.
> > ~~~~~~~
> > 
> > Is there a reason why some diagnostics only have a cursor pointing to the
> > beginning of a token, while others are underlined properly?
> 
> This isn't a question of "properly" or not - you'll notice that the things
> underlined could actually, in other contexts, be more than one token (eg:
> (1 + 2) + "foo" the LHS is (1 + 2) is underlined, and in "foo(0)" it's
> possible that 'foo' could be a more complex expression involving a fully
> qualified function name, decltype, etc). I suppose arguably the 'foobar'
> example could involve a fully qualified (nested) name too.

Right, properly is the wrong word.

To rephrase: I propose to add ranges to "top-level" diagnostics. In the 
example above, that would mean adding a range to the "redifinition of 
'foobar'.

> > For the child diagnostics pointing to the candidate function it's fine to
> > only
> > get a cursor. But for the redefinition of 'foobar' I'd expect a range.
> > Similar
> > for diagnostics related to not-found #include statements.
> > 
> > Would patches be accepted to add ranges to these diagnostics? Where would
> > I
> > have to look in the codebase?
> 
> If we decide that's the right direction (that all diagnostic locations
> should highlight the entire token, rather than just use a caret to point to
> the start) we should probably just fix the diagnostic printer, rather than
> fixing every diagnostic call site.

Me as a consumer of the clang-c API also need to have that information. Thus 
we'll need to store the ranges into the diagnostics anyways - no? The printers 
should then just work™.

Or how would you implement this purely on the diagnostic printer side? How do 
you get the token at a cursor position with the C-API? We tried 
clang_Cursor_getSpellingNameRange but didn't get good results.

Thanks
-- 
Milian Wolff
mail at milianw.de
http://milianw.de