[cfe-commits] [PATCH] [clang.py] Refactor how ctypes functions are registered

Manuel Klimek klimek at google.com
Mon Jun 25 00:47:34 PDT 2012


+    #lib.clang_annotateTokens.argtype = [TranslationUnit, POINTER(Token),
+    #                                    c_uint, POINTER(Cursor)]

Is this intentionally commented out?

In general, I like the patch - it's pretty straight forward, so the biggest
concerns would be high level.
Perhaps you can loop in whoever originally designed the API for an opinion
:)

Cheers,
/Manuel



On Sat, Jun 23, 2012 at 7:23 AM, Gregory Szorc <gregory.szorc at gmail.com>wrote:

> I've been wanting to do this for a while: this patch refactors how the
> libclang functions are registered in the Python bindings.
>
> Instead of creating a separate symbol for each libclang function, we
> perform the ctypes magic directly on an instance of the libclang
> library. Things are defined in a function in the rare case someone
> wants to have multiple handles to the libclang library.
>
> This increases the cohesion between libclang and the Python bindings
> and IMO makes the Python easier to read since you don't need to
> maintain a mapping from the Python function name to the libclang
> function name.
>
> Since this deletes symbols from the module, this is technically
> backwards incompatible. But, I would argue that people should never
> have been using these symbols directly (they offer little benefit
> without the classes in the module).
>
> This will bit rot the compilation database patch that is pending
> review on this list. I don't like bit rotting people, so I may hold
> off landing this until after that patch.
>
> There is a high risk of typos in this patch. The nose tests all pass,
> but our test coverage isn't perfect.
>
> Some function definitions from missing features (tokens, resource
> usage) are commented out because I cherry-picked this patch from my
> personal branch and these features were implemented in that branch
> before this patch. I'll simply remove the comments once those
> corresponding features land (which will be shortly, I hope).
>
> Gregory
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120625/81c22f4c/attachment.html>


More information about the cfe-commits mailing list