[cfe-dev] Any known issues with clang_getDiagnosticNumRanges() in libclang?
David Blaikie
dblaikie at gmail.com
Tue Apr 22 16:11:10 PDT 2014
On Tue, Apr 22, 2014 at 4:04 PM, Michael Bolin <bolinfest at gmail.com> wrote:
> If you want to underline the error in an editor (rather than just having a
> red X in the gutter), it's a lot easier if the diagnostic includes the
> source range for you so you don't have to infer/calculate it yourself.
Sure - perhaps a wrapper API could be provided, but adding that range
to every diagnostic at the fundamental level isn't desirable so far as
I'm aware.
> For diagnostics with no source range, do you think it's currently reliable
> to find the token at the location and underline it?
Yes.
> I'm not sure. For
> example, if you are missing a semicolon at the end of a line, it would be
> nice if the expression with the missing semicolon were underlined to draw
> attention to it.
That would be an example where a range could be added to a diagnostic,
if it was beneficial to users.
>
>
> On Tue, Apr 22, 2014 at 3:42 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> On Tue, Apr 22, 2014 at 3:31 PM, Michael Bolin <bolinfest at gmail.com>
>> wrote:
>> > Ah, if the contents of example.c are simply:
>> >
>> > main() {}
>> >
>> > And then I run:
>> >
>> > clang example.c
>> >
>> > I get:
>> >
>> > example.c:1:1: warning: type specifier missing, defaults to 'int'
>> > [-Wimplicit-int]
>> > main() {}
>> > ^~~~
>> > 1 warning generated.
>> >
>> > So there are ranges, just not for as many diagnostic types as I would
>> > expect. Would patches to add more range information be welcome?
>>
>> Depends if they add value - in the case of the return example, the
>> diagnostic points to the one token that's relevant - it's not
>> necessary to describe that with a range. (it could be a purely UI
>> level feature to have diagnostics tokens be displayed as highlighted
>> ranges - but it's not necessary to have all the diagnostics manually
>> add the range of their one token to the diagnostic)
>>
>> Not sure what else might end up highlighted in your 'main' example
>> (ie: why there's a range there since it's only over one token - I
>> assume it's because it might be over multiple tokens in some cases,
>> but don't know what those cases are)
>>
>> - David
>>
>> >
>> >
>> >
>> > On Tue, Apr 22, 2014 at 3:26 PM, Michael Bolin <bolinfest at gmail.com>
>> > wrote:
>> >>
>> >> Hmm, I just tried running `clang -fdiagnostics-print-source-range-info
>> >> example.c` and I got:
>> >>
>> >> example.c:5:3: error: use of undeclared identifier 'retur'
>> >> retur 0;
>> >> ^
>> >> 1 error generated.
>> >>
>> >> So this has a caret identifying the source location, but there aren't
>> >> any
>> >> tildes showing the source range, as I would expect. From
>> >> http://clang.llvm.org/diagnostics.html, I would expect most diagnostics
>> >> to
>> >> include a range.
>> >>
>> >>
>> >>
>> >> On Tue, Apr 22, 2014 at 3:19 PM, Michael Bolin <bolinfest at gmail.com>
>> >> wrote:
>> >>>
>> >>> I am now calling clang_getDiagnosticNumRanges() from C and still get
>> >>> zero
>> >>> for the number of ranges. Here is my C code (main.c) that creates a
>> >>> CXTranslationUnit for a malformed file and dumps its diagnostics:
>> >>>
>> >>> https://gist.github.com/bolinfest/11196200
>> >>>
>> >>> Here is the malformed file, example.c, that I am using for testing:
>> >>>
>> >>> https://gist.github.com/bolinfest/11196225
>> >>>
>> >>> And here is the output when I run `./main.o example.c`:
>> >>>
>> >>> https://gist.github.com/bolinfest/11196241
>> >>>
>> >>> As you can see, I can get pretty much everything for the diagnostic
>> >>> (source location, category id, category name), but no source location.
>> >>> I
>> >>> would expect to get a source range associated that identifies the
>> >>> misspelled
>> >>> keyword. Any ideas? Are my expectations just wrong?
>> >>>
>> >>> Thank you,
>> >>> Michael
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Apr 18, 2014 at 1:06 PM, Michael Bolin <bolinfest at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> I am using the Python wrapper for libclang (cindex.py), and none of
>> >>>> my
>> >>>> diagnostics have any SourceRanges associated with them. When I create
>> >>>> the
>> >>>> translation unit, I even make sure that -fprint-source-range-info and
>> >>>> -fdiagnostics-print-source-range-info are passed as arguments (though
>> >>>> I
>> >>>> don't know if that is strictly necessary).
>> >>>>
>> >>>> AFAICT, I believe that the Python calling and configuration code is
>> >>>> correct:
>> >>>>
>> >>>> conf.lib.clang_getDiagnosticNumRanges(self.diag)
>> >>>>
>> >>>> ("clang_getDiagnosticNumRanges",
>> >>>> [Diagnostic],
>> >>>> c_uint),
>> >>>>
>> >>>> Are there any suggestions on how to debug this besides writing
>> >>>> against
>> >>>> libclang directly in C to make sure everything is working there?
>> >>>>
>> >>>> Thank you,
>> >>>> Michael
>> >>>>
>> >>>
>> >>
>> >
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >
>
>
More information about the cfe-dev
mailing list