Fix documentation grammar, typos, and clarity issues (#228)

Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>

Author: DimitriPapadopoulos

README.md

@@ -29,7 +29,7 @@ Contact
 Testing/development tips
 ------------------------
 
-After `git clone` or `wget && tar`, we will get a directory called `cffi` or `cffi-x.x.x`. we call it `repo-directory`. To run tests under CPython, run the following in the `repo-directory`:
+After `git clone` or `wget && tar`, we will get a directory called `cffi` or `cffi-x.x.x`. We call it `repo-directory`. To run tests under CPython, run the following in the `repo-directory`:
 
     pip install pytest
     pip install -e .  # editable install of CFFI for local development

doc/source/cdef.rst

@@ -437,7 +437,7 @@ least ``libraries=['foo']`` in order to link with ``libfoo.so`` or
 ``libfoo.so.X.Y``, or ``foo.dll`` on Windows.  The ``sources`` is a
 list of extra .c files compiled and linked together (the file
 ``module_name.c`` shown above is always generated and automatically added as the
-first argument to ``sources``).  See the distutils documentations for
+first argument to ``sources``).  See the distutils documentation for
 `more information about the other arguments`__.
 
 .. __: https://setuptools.pypa.io/en/stable/userguide/ext_modules.html#building-extension-modules
@@ -482,7 +482,7 @@ Letting the C compiler fill the gaps
 
 If you are using a C compiler ("API mode"), then:
 
-*  functions taking or returning integer or float-point arguments can be
+*  functions taking or returning integer or floating-point arguments can be
    misdeclared: if e.g. a function is declared by ``cdef()`` as taking a
    ``int``, but actually takes a ``long``, then the C compiler handles the
    difference.

doc/source/installation.rst

@@ -10,7 +10,7 @@ Quick installation for CPython (cffi is distributed with PyPy):
 
 .. __: http://pypi.python.org/pypi/cffi
 
-In more details:
+In more detail:
 
 This code has been developed on Linux, but should work on any POSIX
 platform as well as on Windows 32 and 64.  (It relies occasionally on
@@ -53,8 +53,8 @@ Download and Installation:
 * Or grab the most current version from `GitHub`_:
   ``git clone https://github.com/python-cffi/cffi``
 
-* running the tests: ``pytest  c/  testing/`` (if you didn't
-  install cffi yet, you need first ``python setup_base.py build_ext -f
+* running the tests: ``pytest c/ testing/`` (if you didn't
+  install cffi yet, you need to first run ``python setup_base.py build_ext -f
   -i``)
 
 .. _`GitHub`: https://github.com/python-cffi/cffi
@@ -79,8 +79,8 @@ Platform-specific instructions
 ``libffi`` is notoriously messy to install and use --- to the point that
 CPython includes its own copy to avoid relying on external packages.
 CFFI does the same for Windows, but not for other platforms (which should
-have their own working libffi's).
-Modern Linuxes work out of the box thanks to ``pkg-config``.  Here are some
+have their own working libffi).
+Modern Linux distributions work out of the box thanks to ``pkg-config``.  Here are some
 (user-supplied) instructions for other platforms.
 
 

doc/source/overview.rst

@@ -308,7 +308,7 @@ with the files ``pi.c`` and ``pi.h``:
       # include <math.h>
 
       /* Returns a very crude approximation of Pi
-         given a int: a number of iteration */
+         given an int: a number of iterations */
       float pi_approx(int n){
 
         double i,x,y,sum=0;
@@ -430,7 +430,7 @@ mode and the in-line ABI mode.  It lets you use the ABI mode, with its
 advantages (not requiring a C compiler) and problems (crashes more
 easily).
 
-This mixture mode lets you massively reduces the import times, because
+This mixture mode lets you massively reduce the import times, because
 it is slow to parse a large C header.  It also allows you to do more
 detailed checkings during build-time without worrying about performance
 (e.g. calling :ref:`cdef() <cdef>` many times with small pieces of declarations,
@@ -644,7 +644,7 @@ use of a C global variable:
       if __name__ == "__main__":
           ffibuilder.compile(verbose=True)
 
-The way that the ``increment`` uses the ``value`` global variable is not
+The way that ``increment`` uses the ``value`` global variable is not
 thread-safe. `Data races
 <https://en.wikipedia.org/wiki/Race_condition#Data_race>`_ are possible if two
 threads simultaneously call ``increment``. We can engineer that situation with a

doc/source/using.rst

@@ -391,7 +391,7 @@ pointers, with each of them only valid during the corresponding call.  This is
 important notably for PyPy which uses many optimizations tweaking the data
 underlying a byte string object.  CFFI will not make and free a copy of
 the whole string at *every* call---it usually won't---but you *cannot*
-write code that relies on it: there are cases were that would break.
+write code that relies on it: there are cases where that would break.
 If you need a pointer to remain valid, you need to make one explicitly,
 for example with ``ptr = ffi.new("char[]", x)``.)
 
@@ -532,7 +532,7 @@ but it makes the next GC occur earlier, which is often enough.
 
 The same applies if the memory allocations are indirect, e.g. the C
 function allocates some internal data structures.  In that case, call
-``__pypy__.add_memory_pressure(n)`` with an argument ``n`` that is an
+``__pypy__.add_memory_pressure(n)`` with an argument ``n`` that is a
 rough estimation.  Knowing the exact size is not important, and memory
 pressure doesn't have to be manually brought down again after calling
 the freeing function.  If you are writing wrappers for the allocating /

doc/source/whatsnew.rst

@@ -19,7 +19,7 @@ v1.17.1
 =======
 
 * Fix failing ``distutils.msvc9compiler`` imports under Windows (`#118`_).
-* ``ffibuilder.emit_python_code()`` and ``ffibuiler.emit_c_code()`` accept file-like objects (`#115`_).
+* ``ffibuilder.emit_python_code()`` and ``ffibuilder.emit_c_code()`` accept file-like objects (`#115`_).
 * ``ffiplatform`` calls are bypassed by ``ffibuilder.emit_python_code()`` and ``ffibuilder.emit_c_code()`` (`#81`_).
 
 .. _`#118`: https://github.com/python-cffi/cffi/pull/118