Support a new CLANG_LIBRARY_PATH environment variable for the Python
binding tests. This variable can be used to force the bindings to load
libclang.* from a specific directory.
I plan to use this when integrating Python binding tests with the CMake
build system. Currently, those tests load libclang.so from default
search paths, so I would have to rely on platform-specific mechanics
such as LD_LIBRARY_PATH. Instead of copying the whole logic necessary
to handle platform differences into yet another place, it's easier to
just add a dedicated variable for this purpose.
Differential Revision: https://reviews.llvm.org/D52806
llvm-svn: 344240
Rewrite the tests from using plain 'assert' mixed with some nosetests
methods to the standard unittest module layout. Improve the code
to use the most canonical assertion methods whenever possible.
This has a few major advantages:
- the code uses standard methods now, resulting in a reduced number
of WTFs whenever someone with basic Python knowledge gets to read it,
- completely unnecessary dependency on nosetests is removed since
the standard library supplies all that is necessary for the tests
to run,
- the tests can be run via any test runner, including the one built-in
in Python,
- the failure output for most of the tests is improved from 'assertion
x == y failed' to actually telling the values.
Differential Revision: https://reviews.llvm.org/D39763
llvm-svn: 317897
o) Add a 'Location' class that represents the four properties of a
physical location
o) Enhance 'SourceLocation' to provide 'expansion' and 'spelling'
locations, maintaining backwards compatibility with existing code by
forwarding the four properties to 'expansion'.
o) Update the implementation to use 'clang_getExpansionLocation'
instead of the deprecated 'clang_getInstantiationLocation', which
has been present since 2011.
o) Update the implementation of 'clang_getSpellingLocation' to actually
obtain spelling location instead of file location.
llvm-svn: 316278
There is no type checking in __eq__, so ctypes will throw if the wrong
Python type is passed in to the C function. Personally, I feel garbage
in means garbage out and it isn't worth testing for this explicitly.
Contributed by: Gregory Szorc <gregory.szorc@gmail.com>
llvm-svn: 149824
Michal Gorny