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

[Gregory Szorc]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-clang.py-Refactor-how-ctypes-functions-are-registere.patch
Type: text/x-patch
Size: 75468 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120622/769f44af/attachment.bin>