Rename `get_version` to `get_clang_version` to match the `libclang.so`
name[1], and be clear we doesn't return some `cindex.py` internal
versioning but the `libclang.so` one.
[1] This match was some current API are doing for example
`conf.lib.clang_getArraySize` is mapped to `get_array_size`.
It's useful to know which clang library the python bindings are running.
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
To maintain consistency with other classes mirrored from libclang, the
`_CX` prefix should be removed.
The old name is introduced as a subclass of the renamed class, and
deprecation warnings are added on every attribute access.
This adds type annotations to the `TranslationUnit` class, enough to
pass a strict typecheck. This resolves 19 strict typing errors as the
next step towards https://github.com/llvm/llvm-project/issues/76664
This PR replaces string concatenations and the older `%` string
interpolation with `str.format`. Changes along those lines were
originally a part of #173845, but they were moved to a new PR,
where it was decided that `str.format` is preferable over
f-strings.
Changes in this commit are identical to
abf1d0bea04ab5d5ed1be3708ce1cd86707d5c8f, but commit title and
description were changed to correctly reflect the changes.
This reverts commit abf1d0bea04ab5d5ed1be3708ce1cd86707d5c8f,
because its title and description are entirely wrong.
f-strings is what was initially proposed, but then it was decided
to go with `str.format`.
This PR replaces string concatenations and the older `%` string
interpolation with fstrings. These changes were originally part of
#173845 but have been moved to a new PR.
This adds type annotations to the `SourceLocation` and `SourceRange`
classes, enough to pass a strict typecheck. This resolves 29 strict
typing errors as the next step towards
https://github.com/llvm/llvm-project/issues/76664
This adresses point 2 from
https://github.com/llvm/llvm-project/issues/156680.
Also add a dummy object that serves as an alias to `SPELLING_CACHE`,
used to replicate the old behavior and throw a `DeprecationWarning`.
This adresses point 4 from #156680. This is a necessary step before
`CompletionChunk.Kind` can be removed.
The `ChunkCompletion.Kind` implements `__str__` and `__repr__`
differently from our other enum classes. I have adapted the `__repr__`
of `CompletionString` to stringify the availability of the chunk
differently so that it still looks the same as before.
Also introduce a temporary `AvailabilityKindCompat` to ensure that
`__str__` returns the same format, while also leaving a deprecation
warning that this will be removed in a future release.
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
Close#167421
This PR adds the environment variables ``LIBCLANG_LIBRARY_PATH`` and
``LIBCLANG_LIBRARY_FILE``, which allow users to specify the directory
path and the exact library file that should be used to locate libclang.
---------
Co-authored-by: Jannick Kremer <jannick.kremer@mailbox.org>
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
This adds a pyproject.toml file for packaging the clang Python bindings
as a sdist tarball and pure Python wheel packages for the clang python
bindings. It is required to move updates of the clang and libclang PyPI
packages to the LLVM monorepo. Versioning information is derived from
LLVM git tags (using hatch-vcs, which is based on setuptools_scm), so no
manual updates are needed to bump version numbers. The minimum python
version required is set to 3.10 due to cindex.py using PEP 604 union
type syntax (str | bytes | None).
The .git_archival.txt file is populated with version information needed
to get accurate version information if the bindings are installed from
an LLVM/clang source code archive. The .gitignore file is populated with
files that may get created as part of building/testing the sdist and
wheel that should not be committed to source control.
This is first step for addressing #125220, and moving publishing of the
clang and libclang PyPI packages into the LLVM monorepo.
Signed-off-by: Ryan Mast <mast.ryan@gmail.com>
In the previous implementation, 43 libclang functions are registered in
FUNCTION_LIST with return type ctypes.c_bool. However, none of these
functions actually return a C bool type; instead, they return unsigned
or signed integers (unsigned int / int) on the C side.
Although ctypes automatically casts nonzero integers to True and zero to
False, this implicit conversion hides the "true" c-return type.
This PR updates those functions to use their proper “native” ctypes
return types (c_uint or c_int) and updates the corresponding Python
convenience wrappers to explicitly cast their results using the bool
constructor.
As a side effect, the related `# type: ignore` annotations have been
removed, as they are no longer necessary.
Some libclang functions are used directly without any intermediate
Python wrapper. These functions (`clang_equalCursors`,
`clang_equalLocations`, `clang_equalRanges`, `clang_equalTypes`,
`clang_File_isEqual`, and `clang_isFileMultipleIncludeGuarded`) are now
explicitly cast to bool at their call sites. Note that
`clang_isFileMultipleIncludeGuarded` is never called in the binding.
Thix fix#164915.
Since https://github.com/llvm/llvm-project/pull/138103 , the `Cursor`
class throws an error when any of its methods is called on a null
cursor. Simultaneously, we adapted all methods to return `None` instead
of a null cursor, so users should not encounter these. We have
overlooked one way to end up with null cursors, namely the
`Token.cursor` property, which may return null cursors under some
circumstances.
Fixes#163180
This change implements the fuse directive, `#pragma omp fuse`, as specified in the OpenMP 6.0, along with the `looprange` clause in clang.
This change also adds minimal stubs so flang keeps compiling (a full implementation in flang of this directive is still pending).
---------
Co-authored-by: Roger Ferrer Ibanez <roger.ferrer@bsc.es>
Add tests to ensure that all C-enum variants are defined on Python side,
and that the Python bindings do not contain variants not defined on the C side
This fully annotates the code completion classes (CompletionChunk,
CompletionString, CodeCompletionResult, CodeCompletionResults and
CCRStructure) resolving 59 strict typing errors as the next step towards
#76664
A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
ff03db6657
However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:
`if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")`
which becomes:
`if (AIX MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`
You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:

This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes#136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- If `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-superfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate.
- AArch64 doesn't `FAIL` any longer, so no `XFAIL` is necessary.
- It keeps the `check-clang-python` target for use by the Clang Python
CI.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- If `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-superfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
- It keeps the `check-clang-python` target for use by the Clang Python
CI.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.