Update cffi to 1.13.0

[pyup-bot]

This PR updates cffi from 1.11.0 to 1.13.0.

Changelog

1.12.3

=======

* Fix for nested struct types that end in a var-sized array (405).

* Add support for using ``U`` and ``L`` characters at the end of integer
constants in ``ffi.cdef()`` (thanks Guillaume).

* More 3.8 fixes.

1.12.2

=======

* Added temporary workaround to compile on CPython 3.8.0a2.

1.12.1

=======

* CPython 3 on Windows: we again no longer compile with ``Py_LIMITED_API``
by default because such modules *still* cannot be used with virtualenv.
The problem is that it doesn't work in CPython <= 3.4, and for
technical reason we can't enable this flag automatically based on the
version of Python.

Like before, `Issue 350`_ mentions a workaround if you still want
the ``Py_LIMITED_API`` flag and *either* you are not concerned about
virtualenv *or* you are sure your module will not be used on CPython
<= 3.4: pass ``define_macros=[("Py_LIMITED_API", None)]`` to the
``ffibuilder.set_source()`` call.

1.12

=====

* `Direct support for pkg-config`__.

* ``ffi.from_buffer()`` takes a new optional *first* argument that gives
the array type of the result.  It also takes an optional keyword argument
``require_writable`` to refuse read-only Python buffers.

* ``ffi.new()``, ``ffi.gc()`` or ``ffi.from_buffer()`` cdata objects
can now be released at known times, either by using the ``with``
keyword or by calling the new ``ffi.release()``.

* Windows, CPython 3.x: cffi modules are linked with ``python3.dll``
again.  This makes them independant on the exact CPython version,
like they are on other platforms.  **It requires virtualenv 16.0.0.**

* Accept an expression like ``ffi.new("int[4]", p)`` if ``p`` is itself
another cdata ``int[4]``.

* CPython 2.x: ``ffi.dlopen()`` failed with non-ascii file names on Posix

* CPython: if a thread is started from C and then runs Python code (with
callbacks or with the embedding solution), then previous versions of
cffi would contain possible crashes and/or memory leaks.  Hopefully,
this has been fixed (see `issue 362`_).

* Support for ``ffi.cdef(..., pack=N)`` where N is a power of two.
Means to emulate ``pragma pack(N)`` on MSVC.  Also, the default on
Windows is now ``pack=8``, like on MSVC.  This might make a difference
in corner cases, although I can't think of one in the context of CFFI.
The old way ``ffi.cdef(..., packed=True)`` remains and is equivalent
to ``pack=1`` (saying e.g. that fields like ``int`` should be aligned
to 1 byte instead of 4).

.. __: cdef.htmlpkgconfig
.. _`issue 362`: https://bitbucket.org/cffi/cffi/issues/362/


Older Versions
==============

1.11.5

-------

* `Issue 357`_: fix ``ffi.emit_python_code()`` which generated a buggy
Python file if you are using a ``struct`` with an anonymous ``union``
field or vice-versa.

* Windows: ``ffi.dlopen()`` should now handle unicode filenames.

* ABI mode: implemented ``ffi.dlclose()`` for the in-line case (it used
to be present only in the out-of-line case).

* Fixed a corner case for ``setup.py install --record=xx --root=yy``
with an out-of-line ABI module.  Also fixed `Issue 345`_.

* More hacks on Windows for running CFFI's own ``setup.py``.

* `Issue 358`_: in embedding, to protect against (the rare case of)
Python initialization from several threads in parallel, we have to use
a spin-lock.  On CPython 3 it is worse because it might spin-lock for
a long time (execution of ``Py_InitializeEx()``).  Sadly, recent
changes to CPython make that solution needed on CPython 2 too.

* CPython 3 on Windows: we no longer compile with ``Py_LIMITED_API``
by default because such modules cannot be used with virtualenv.
`Issue 350`_ mentions a workaround if you still want that and are not
concerned about virtualenv: pass a ``define_macros=[("Py_LIMITED_API",
None)]`` to the ``ffibuilder.set_source()`` call.

.. _`Issue 345`: https://bitbucket.org/cffi/cffi/issues/345/
.. _`Issue 350`: https://bitbucket.org/cffi/cffi/issues/350/
.. _`Issue 358`: https://bitbucket.org/cffi/cffi/issues/358/
.. _`Issue 357`: https://bitbucket.org/cffi/cffi/issues/357/

1.11.4

-------

* Windows: reverted linking with ``python3.dll``, because
virtualenv does not make this DLL available to virtual environments
for now.  See `Issue 355`_.  On Windows only, the C extension
modules created by cffi follow for now the standard naming scheme
``foo.cp36-win32.pyd``, to make it clear that they are regular
CPython modules depending on ``python36.dll``.

.. _`Issue 355`: https://bitbucket.org/cffi/cffi/issues/355/

1.11.3

-------

* Fix on CPython 3.x: reading the attributes ``__loader__`` or
``__spec__`` from the cffi-generated lib modules gave a buggy
SystemError.  (These attributes are always None, and provided only to
help compatibility with tools that expect them in all modules.)

* More Windows fixes: workaround for MSVC not supporting large
literal strings in C code (from
``ffi.embedding_init_code(large_string)``); and an issue with
``Py_LIMITED_API`` linking with ``python35.dll/python36.dll`` instead
of ``python3.dll``.

* Small documentation improvements.

1.11.2

-------

* Fix Windows issue with managing the thread-state on CPython 3.0 to 3.5

1.11.1

-------

* Fix tests, remove deprecated C API usage

* Fix (hack) for 3.6.0/3.6.1/3.6.2 giving incompatible binary extensions
(cpython issue `29943`_)

* Fix for 3.7.0a1+

.. _`29943`: https://bugs.python.org/issue29943

Links

• PyPI: https://pypi.org/project/cffi
• Changelog: https://pyup.io/changelogs/cffi/
• Docs: http://cffi.readthedocs.org

[coveralls]

Coverage increased (+0.06%) to 30.441% when pulling 4240d4f on pyup-update-cffi-1.11.0-to-1.13.0 into 8613d9d on master.

[pyup-bot]

Closing this in favor of #342