https://github.com/rorth closed https://github.com/llvm/llvm-project/pull/142353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
Superceded by PR #142948.
https://github.com/llvm/llvm-project/pull/142353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rorth wrote:
I've now created PR #142948 with an initial implementation of `lit` integration
of the `clang` Python bindings tests.
https://github.com/llvm/llvm-project/pull/142353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.l
Endilll wrote:
We generally avoid XFAIL tests, instead we do normal tests where we expect the
wrong behavior and leave a TODO.
In this case UNSUPPORTED makes more sense.
https://github.com/llvm/llvm-project/pull/142353
___
cfe-commits mailing list
cfe
rorth wrote:
FWIW I now have a prototype of the python tests within the `lit` framework.
The basics (`PASS` if `python` and `libclang.so` match, `FAIL` if not) work,
but there's more to be done:
- The test should be `UNSUPPORTED` when `libclang.so` cannot be loaded.
- The various ways `RUN_PYT
rorth wrote:
> @rorth Now that #142371 is merged, can you re-evaluate this PR and update the
> description?
This PR changed the output from completely silent to excessively verbose: I now
get
```
FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
/var/llvm/local-i386-rele
rorth wrote:
> and couldn't find much on it either, but that sounds like
>
> > Alternatively, as I suggested, one could wrap the actual python -m unittest
> > discover invocation with a check if libclang.so is loadable at all, only
> > then running the actual test.
Indeed: one should move the
DeinAlptraum wrote:
I am unfortunately not at all familiar with how exactly the other tests are
integrated and produce the outputs you described:
> One problem with all these approaches, as I'd already mentioned, is that the
> test outcome isn't properly reported, nor can one use the usual mach
Endilll wrote:
@rorth Now that https://github.com/llvm/llvm-project/pull/142371 is merged, can
you re-evaluate this PR and update the description?
https://github.com/llvm/llvm-project/pull/142353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
rorth wrote:
> > trying to load a 32-bit libclang.so into a 64-bit python is always an
> > error, testsuite or no.
>
> That's why you shouldn't return an exit code of 0 when this error occurs.
> Moreover, this seems like a workaround for that one specific issue you
> encountered. To connect t
DeinAlptraum wrote:
> Besides, one could just change the wording of the warning message: trying to
> load a 32-bit libclang.so into a 64-bit python is always an error, testsuite
> or no.
That's why you shouldn't return an exit code of 0 when this error occurs.
Moreover, this seems like a worka
DeinAlptraum wrote:
> Given the fact that OSError already contains the message that indicates the
> problem, I think we should explore why it's not properly emitted in the first
> place, before introducing bespoke ways of delivering error messages.
> @DeinAlptraum any thoughts here?
This has
rorth wrote:
> Thank you for the PR. Several points:
>
> 1. What happens on Windows?
I have no idea, knowing nothing at all about Windows. I cannot even tell if a
similar situation can arise there, i.e. if you can execute 32-bit programs on a
64-bit Windows and, if you can, what the mess
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/142353
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll commented:
Thank you for the PR. Several points:
1) What happens on Windows?
2) `check-clang-python` is just one of the ways to run into this. `cindex.py`
is a user-facing interface, so we shouldn't emit messages that make sense only
during development.
3) The fact th
https://github.com/rorth created
https://github.com/llvm/llvm-project/pull/142353
When building a 32-bit `clang` on a 64-bit system (like `i686-pc-linux-gnu` on
a Linux/x86_64 system), `ninja check-all` fails:
```
FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
tools/c
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Rainer Orth (rorth)
Changes
When building a 32-bit `clang` on a 64-bit system (like `i686-pc-linux-gnu` on
a Linux/x86_64 system), `ninja check-all` fails:
```
FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
tools
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r HEAD~1...HEAD clang/bindings/python/clang/cindex.py
``
View the diff from dark
18 matches
Mail list logo
