Any known issues with clang_getDiagnosticNumRanges() in libclang?

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

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

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.

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?

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

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.

For diagnostics with no source range, do you think it’s currently reliable to find the token at the location and underline it? 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.

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.