python-cffi/cffi

Missing complex types in cached btypes

Closed this issue · 4 comments

michalhabera commented

As of version 1.17.0 python3 -c "import cffi; ffi = cffi.FFI(); print(ffi.typeof('double _Complex'))"
gives me

root@150c1467a397:/home/dolfinx/python/demo# python3 -c "import cffi; ffi = cffi.FFI(); print(ffi.typeof('double _Complex'))"
Traceback (most recent call last):
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/api.py", line 183, in _typeof
    result = self._parsed_types[cdecl]
             ~~~~~~~~~~~~~~~~~~^^^^^^^
KeyError: 'double _Complex'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/api.py", line 437, in _get_cached_btype
    BType = self._cached_btypes[type]
            ~~~~~~~~~~~~~~~~~~~^^^^^^
KeyError: <_cffi_double_complex_t>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/model.py", line 58, in get_cached_btype
    BType = ffi._cached_btypes[self]
            ~~~~~~~~~~~~~~~~~~^^^^^^
KeyError: <_cffi_double_complex_t>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/api.py", line 200, in typeof
    return self._typeof(cdecl)
           ^^^^^^^^^^^^^^^^^^^
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/api.py", line 186, in _typeof
    result = self._typeof_locked(cdecl)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/api.py", line 175, in _typeof_locked
    btype = self._get_cached_btype(type)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/api.py", line 440, in _get_cached_btype
    BType = type.get_cached_btype(self, finishlist)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/model.py", line 60, in get_cached_btype
    BType = self.build_backend_type(ffi, finishlist)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/model.py", line 175, in build_backend_type
    return global_cache(self, ffi, 'new_primitive_type', self.name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/dolfinx-env/lib/python3.12/site-packages/cffi/model.py", line 598, in global_cache
    res = getattr(ffi._backend, funcname)(*args)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: '_cffi_double_complex_t'

while for 1.16.0 this worked. I've also noticed that CompiledFFI that has complex types declared does recognize complex types. Did complex types cache go missing with recent changes or is this behaviour on purpose (for Win platform compatibility)?

arigo commented

Thanks for noticing this problem! It's a regression caused by the recent Windows compatibility changes. It should be fixed in PR #111, if you want to check it out.

nitzmahone commented

@michalhabera are you able to verify that the fix in #111 corrects the issue you're seeing?

Assuming your test host has compilers/headers installed, you can install the PR merge target directly for testing with (your python interpreter here) -m pip install cffi@git+https://github.com/python-cffi/cffi.git@refs/pull/111/merge -v:

(tmp-71ffbd6e6119430) mdavis@mdavis-p1:/tmp$ python3.12 -m pip install cffi@git+https://github.com/python-cffi/cffi.git@refs/pull/111/merge -v
Using pip 24.2 from /home/mdavis/.virtualenvs/tmp-71ffbd6e6119430/lib/python3.12/site-packages/pip (python 3.12)
Collecting cffi@ git+https://github.com/python-cffi/cffi.git@refs/pull/111/merge
(...)
Building wheels for collected packages: cffi
(...)
Successfully built cffi
Installing collected packages: pycparser, cffi
Successfully installed cffi-1.18.0.dev0 pycparser-2.22

(tmp-71ffbd6e6119430) mdavis@mdavis-p1:/tmp$ python3.12 -m pip show cffi
Name: cffi
Version: 1.18.0.dev0
(...)

If you can install the proposed fix branch that way and verify locally that the fix works for you, we can get that merged for 1.18.0, and possibly backport for a future 1.17.2. Thanks!

michalhabera commented

Thanks @arigo, @nitzmahone ! I can confirm #111 fixes the issue.

  • 🎉1
nitzmahone commented

(also created a 1.17 backport at #127)