[cfe-dev] Ranges for diagnostics

[David Blaikie]

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.


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


>
> Thanks
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140124/ee1bedca/attachment.html>