[cfe-dev] Dealing with parse errors with Python bindings of libclang

[Vedant Kumar via cfe-dev]

Hi Ethan,

> On Aug 13, 2016, at 3:45 PM, Jonathan Coe <jonathanbcoe at gmail.com> wrote:
> 
> 
> 
> On 13 Aug 2016, at 22:33, Ethan Smith via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
>> Thanks for your reply vedant,
>> 
>> I think I might work on a patch. It seems if I use clang_createTranslationUnitFromSourceFile, I can pass the return as the TranslationUnit parameter for clang_parseTranslationUnit2.

That doesn't sound quite right to me. The `out_TU' parameter looks like an
in-out parameter. Initializing it beforehand might work, but would be redundant
and (probably) leaky. I suggest using the API like this:

  CXTranslationUnit TU;
  enum CXErrorCode CXErr;
  CXErr = clang_parseTranslationUnit2(..., &TU);


>> After a bit of fiddling, I found that I needed to make my own enum wrapper for CXErrorCode (where should I place the code for this? In cindex near the "Exception Classes" section?), and now I can get the correct return code. 
>> 
>> I was thinking of giving the CXErrorCode in the TranslationUnitLoadError given. (Eg,  "clang.cindex.TranslationUnitLoadError: Error parsing translation unit:  CXError_InvalidArguments")

Sgtm.


>>  
>> 
>> Also, since this moves to clang_parseTranslationUnit2, and there are no other references to the it, should I comment out clang_parseTranslationUnit? Or leave it in?

I assume that you're just changing the python bindings, in which case it's
probably safe to remove all references to the old parseTranslationUnit API.
You'd have to double-check with someone who knows more :).


>> 
>> Also, I should submit this fix once I hear back on the above as a Github PR, correct?
>> 
> 
> I think that GitHub is just a mirror of an SVN repository. I've submitted any patches to LLVM/Clang on Phabricator 
> 
> http://llvm.org/docs/Phabricator.html
> 
> If you look at recent changes to the clang bindings in the history then you can find people who might be able to review your (very welcome) changes.

+ 1. Please submit your patch to reviews.llvm.org, CC cfe-commits, and add
a reviewer or two.

thanks,
vedant

> 
> Regards
> 
> Jon
> 
>> ~>Ethan
>> 
>> On Fri, Aug 12, 2016 at 6:45 PM, Vedant Kumar <vsk at apple.com> wrote:
>> Hi Ethan,
>> 
>> Unfortunately, this is a known bug in the python bindings (see: the FIXME in
>> bindings/clang/cindex.py). The fix here should be to 1) expose a function which
>> can unwrap a CXErrorCode into a more pythonic error value and 2) use that
>> function to help move from the clang_parseTranslationUnit API to
>> clang_parseTranslationUnit2.
>> 
>> If you don't have the time to put together a patch, you might be able to get a
>> debugger to break on clang_parseTranslationUnit and inspect the error state
>> there.
>> 
>> best,
>> vedant
>> 
>> > On Aug 8, 2016, at 10:36 AM, Ethan Smith via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>> >
>> > First off, thanks for the awesome library!
>> >
>> > I am using the Python bindings of libclang. I am trying to use it to parse really any c/c++ library for code generation, however, as an example, I tried to bind libui (https://github.com/andlabs/libui). However, when I try to index.parse after setting up a clang index, I get a TranslationUnitLoadError. Since this returns a null pointer, I can't figure out what went wrong. Is there a way to tell what is causing the parser to fail? I also tried to pass 0x200 ( CXTranslationUnit_KeepGoing) as an option, which should, as I understand it, tell the parser to continue on fail, it has no effect. How can I get some useful information to tell me what I need to do to fix the parser error? For the record, the library compiles fine with clang itself.
>> >
>> > Could I expose more useful info from the c libclang? I suppose I'm not opposed to writing my own bindings.
>> >
>> > Thanks!
>> >
>> > Ethan
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev