[cfe-dev] Status/Future of libclang

[Reece Dunn via cfe-dev]

On 10 July 2016 at 09:23, Jonathan Müller <cfe-dev at lists.llvm.org> wrote:

> On 09.07.2016 17:27, Jonathan Coe via cfe-dev wrote:
>
>>
>> I've written small extensions to libclang and to the python bindings to
>> get a code generator I wrote working. If there is a small number of
>> missing features maybe you could do the same?
>>
>
> Yes, I should start doing that.
>
> On 09.07.2016 18:13, Reece Dunn via cfe-dev wrote:
> >
> > When I was writing by own libclang python bindings
> > (https://github.com/rhdunn/libclangpy) I had to write custom logic on
> > top of the direct bindings to fix bugs in libclang (e.g.
> > CursorKind_LinkageSpec is not mapped to the API, so `extern "C" ...`
> > does not work) and some support for the newer APIs on older versions of
> > libclang.
>
> Did that as well.
>
>
> > I also wrote my own tests for the binding to make sure the APIs worked
> > consistently on the target and later versions of libclang.
>
> Any documentation on how to do that?
>

My approach was to have a custom test driver 'run(version, test)' that
called the test function. This would report a skip message if the function
raised a missing function or unsupported exception (for Unexposed* cursors)
and the libclang version is lower than the one being tested, otherwise it
would report a failure. I then created 'test_[APIType][VERSION]' classes,
e.g. 'test_TranslationUnit29', as well as tests for specific CursorKind
values.

This then allowed me to document libclang behaviour differences. For
libclang version bugs, I would test the libclang version that had the bug
and use the test (with an associated comment) to document the behaviour
difference.

I have 'match_type' and 'match_cursor' helpers that test those objects and
raise unsupported exceptions for unexposed type/cursor kinds.

With the differences documented, I could then work out how to support a
consistent behaviour based on the tests and support newer features (e.g.
access specifiers) on earlier versions.

Thanks,
Reece


> > My verdict was that it was a second class citizen to the unstable C++
> API.
>
> Seems like it.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160710/cea8af08/attachment.html>