[libclang/python] Export all enums

[DeinAlptraum]

This resolves #48212 and also adds the remaining unexposed Enums

[llvmbot]

@llvm/pr-subscribers-clang

Author: Jannick Kremer (DeinAlptraum)

Changes

This resolves #48212 and also adds the remaining unexposed Enums

---

Full diff: https://github.com/llvm/llvm-project/pull/100941.diff

1 Files Affected:

• (modified) clang/bindings/python/clang/cindex.py (+5)

diff --git a/clang/bindings/python/clang/cindex.py b/clang/bindings/python/clang/cindex.py
index be024da5e005c..d9009a8666338 100644
--- a/clang/bindings/python/clang/cindex.py
+++ b/clang/bindings/python/clang/cindex.py
@@ -4077,6 +4077,7 @@ def function_exists(self, name):
 conf = Config()
 
 __all__ = [
+    "AccessSpecifier",
     "AvailabilityKind",
     "BinaryOperator",
     "Config",
@@ -4087,12 +4088,16 @@ def function_exists(self, name):
     "CursorKind",
     "Cursor",
     "Diagnostic",
+    "ExceptionSpecificationKind",
     "File",
     "FixIt",
     "Index",
     "LinkageKind",
+    "RefQualifierKind",
     "SourceLocation",
     "SourceRange",
+    "StorageClass",
+    "TemplateArgumentKind",
     "TLSKind",
     "TokenKind",
     "Token",

[DeinAlptraum]

@Endilll can I ask you for a review again?

[Endilll]

LGTM
I think __all__ can be made a tuple instead, but it's not necessarily in the scope of this PR.

[DeinAlptraum]

Could you also merge please? (or are you waiting for something else?)

Also looked at the docs and it explicitly mentions that __all__ should be a list, though I just tested that tuples also work...

[Endilll]

@DeinAlptraum Can you merge main into this branch? I'd like to merge this with a green CI.

@tbaederr CI for this patch has failed due to unrelated failure that is likely to be connected to your work:

�_bk;t=1722188500258�******************** TEST 'Clang :: AST/Interp/literals.cpp' FAILED ********************
�_bk;t=1722188500258�Exit Code: 1
�_bk;t=1722188500258�
�_bk;t=1722188500258�Command Output (stdout):
�_bk;t=1722188500258�--
�_bk;t=1722188500258�# RUN: at line 1
�_bk;t=1722188500258�c:\ws\src\build\bin\clang.exe -cc1 -internal-isystem C:\ws\src\build\lib\clang\20\include -nostdsysteminc -fexperimental-new-constant-interpreter -Wno-vla -fms-extensions -std=c++11 -verify=expected,both C:\ws\src\clang\test\AST\Interp\literals.cpp
�_bk;t=1722188500258�# executed command: 'c:\ws\src\build\bin\clang.exe' -cc1 -internal-isystem 'C:\ws\src\build\lib\clang\20\include' -nostdsysteminc -fexperimental-new-constant-interpreter -Wno-vla -fms-extensions -std=c++11 -verify=expected,both 'C:\ws\src\clang\test\AST\Interp\literals.cpp'
�_bk;t=1722188500258�# note: command had no output on stdout or stderr
�_bk;t=1722188500258�# RUN: at line 2
�_bk;t=1722188500258�c:\ws\src\build\bin\clang.exe -cc1 -internal-isystem C:\ws\src\build\lib\clang\20\include -nostdsysteminc -fexperimental-new-constant-interpreter -Wno-vla -fms-extensions -std=c++20 -verify=expected,both C:\ws\src\clang\test\AST\Interp\literals.cpp
�_bk;t=1722188500258�# executed command: 'c:\ws\src\build\bin\clang.exe' -cc1 -internal-isystem 'C:\ws\src\build\lib\clang\20\include' -nostdsysteminc -fexperimental-new-constant-interpreter -Wno-vla -fms-extensions -std=c++20 -verify=expected,both 'C:\ws\src\clang\test\AST\Interp\literals.cpp'
�_bk;t=1722188500258�# .---command stderr------------
�_bk;t=1722188500258�# | error: 'both-warning' diagnostics seen but not expected: 
�_bk;t=1722188500258�# |   File C:\ws\src\clang\test\AST\Interp\literals.cpp Line 1219: cast to smaller integer type 'long' from 'void *'
�_bk;t=1722188500258�# | 1 error generated.
�_bk;t=1722188500258�# `-----------------------------
�_bk;t=1722188500258�# error: command failed with exit status: 1
�_bk;t=1722188500258�
�_bk;t=1722188500258�--
�_bk;t=1722188500258�
�_bk;t=1722188500258�********************

This is the second time during the past 7 days that I see AST/Interp tests failing in unrelated PR. Can you make sure pre-commit CI is green before you land your commits? You can open PR, and merge them as long as CI is green. Both Linux and Windows pre-commit CI has enough capacity these days, so it shouldn't introduce too much latency into your workflow.

CC @AaronBallman

[tbaederr]

@tbaederr CI for this patch has failed due to unrelated failure that is likely to be connected to your work:

That should be fixed already, I assume this is using an old version of the test.

[Endilll]

@tbaederr CI for this patch has failed due to unrelated failure that is likely to be connected to your work:

That should be fixed already, I assume this is using an old version of the test.

Sure, but it's annoying then you make a branch from main, only to find out that it's wasn't green.
At the worst, I had to merge from main multiple times before I was able to get rid of unrelated failures in CI, adding an unnecessary CI load.

[DeinAlptraum]

This may be my fault, I don't remember if I pulled main before branching for this PR, especially seeing how my last PR also had unrelated test failures