Merge pull request #424 from Starbuck5/typos

Typo fixes (suggested by codespell)

README.md

@@ -32,7 +32,7 @@ for more details on HPy motivation, goals, and features, for example:
 
   - debug mode for better developer experience
   - support for incremental porting from CPython API to HPy
-  - CPython ABI for raw peformance on CPython
+  - CPython ABI for raw performance on CPython
   - and others
 
 Do you want to see how HPy API looks in code? Check out

c_test/acutest.h

@@ -245,7 +245,7 @@
 #endif
 
 
-/* Common test initialiation/clean-up
+/* Common test initialization/clean-up
  *
  * In some test suites, it may be needed to perform some sort of the same
  * initialization and/or clean-up in all the tests.

docs/api-reference/index.rst

@@ -43,7 +43,7 @@ HPy Helper Functions
 together with the HPy extension's sources. The appropriate source files are
 automatically added to the extension sources. The helper functions will, of
 course, use the core API to interact with the interpreter. The main reason for
-having the helper functions in the HPy extension is to avoid compatiblilty
+having the helper functions in the HPy extension is to avoid compatibility
 problems due to different compilers.
 
 .. toctree::

docs/api.rst

@@ -95,7 +95,7 @@ close a handle twice and that you don't forget to close any.
   identify the precise code locations which created and closed it. This is
   possible because handles are associated with a single call to a C/API
   function. As a result, given a handle that is leaked or used after freeing,
-  it is possible to identify exactly the C/API function that producted it.
+  it is possible to identify exactly the C/API function that produced it.
 
 
 Remember that ``Python.h`` guarantees that multiple references to the same
@@ -182,7 +182,7 @@ There are a couple of points which are worth noting:
     module.
 
   * The actual C function which implements ``myabs`` is called ``myabs_impl``
-    and is infered by the macro. The macro takes the name and adds ``_impl``
+    and is inferred by the macro. The macro takes the name and adds ``_impl``
     to the end of it.
 
   * It uses the ``HPyFunc_O`` calling convention. Like ``METH_O`` in ``Python.h``,

docs/overview.rst

@@ -29,7 +29,7 @@ which makes as few assumptions as possible about the design decisions of any
 implementation of Python, allowing diverse implementations to support it
 efficiently and without compromise**. In particular, **reference counting is not
 part of the API**: we want a more generic way of managing resources that is
-possible to impelement with different strategies, including the existing
+possible to implement with different strategies, including the existing
 reference counting and/or with a moving *Garbage Collector* (like the ones used
 by PyPy, GraalPy or Java, for example). Moreover, each implementation can
 experiment with new memory layout of objects, add optimizations, etc. The

docs/porting-guide.rst

@@ -368,7 +368,7 @@ fill the empty object using ``PyList_SetItem / PyList_SET_ITEM`` or
 
 This is in particular problematic for tuples because they are actually
 immutable. HPy goes a different way and provides a dedicated *builder* API to
-avoid the (temporary) inconsitent state during object initialization.
+avoid the (temporary) inconsistent state during object initialization.
 
 Long story short, doing the same in HPy with builders is still very simple and
 straight forward. Following an example for creating a list:

hpy/debug/src/_debugmod.c

@@ -355,7 +355,7 @@ static UHPy DebugHandle_repr_impl(HPyContext *uctx, UHPy self)
 
 
 HPyDef_METH(DebugHandle__force_close, "_force_close",
-            HPyFunc_NOARGS, .doc="Close the underyling handle. FOR TESTS ONLY.")
+            HPyFunc_NOARGS, .doc="Close the underlying handle. FOR TESTS ONLY.")
 static UHPy DebugHandle__force_close_impl(HPyContext *uctx, UHPy self)
 {
     DebugHandleObject *dh = DebugHandleObject_AsStruct(uctx, self);

hpy/debug/src/debug_ctx_cpython.c

@@ -13,7 +13,7 @@
    for HPy, so uctx contains the logic to call HPy functions from CPython, by
    using _HPy_CallRealFunctionFromTrampoline.
 
-   uctx->ctx_CallRealFunctionFromTrampoline convers PyObject* into UHPy. So
+   uctx->ctx_CallRealFunctionFromTrampoline converts PyObject* into UHPy. So
    for the debug mode we need to:
 
        1. convert the PyObject* args into UHPys.

hpy/debug/src/debug_handles.c

@@ -85,7 +85,7 @@ static void print_error(HPyContext *uctx, const char *message)
     // we just print the exception to stderr and clear it
     // XXX: we should use HPySys_WriteStderr when we have it
     fprintf(stderr, "%s\n", message);
-    //HPyErr_PrintEx(0); // uncommment when we have it
+    //HPyErr_PrintEx(0); // uncomment when we have it
 }
 
 static inline void

hpy/devel/include/hpy.h

@@ -204,7 +204,7 @@ typedef struct { intptr_t _i; } HPyThreadState;
 
 /* Convenience functions to cast between HPy and void*.  We need to decide
    whether these are part of the official API or not, and maybe introduce a
-   better naming convetion. For now, they are needed for ujson. */
+   better naming convention. For now, they are needed for ujson. */
 static inline HPy HPy_FromVoidP(void *p) { return _hconv((intptr_t)p); }
 static inline void* HPy_AsVoidP(HPy h) { return (void*)h._i; }
 

hpy/tools/autogen/pypy.py

@@ -4,7 +4,7 @@
 # this class should probably be moved somewhere in the PyPy repo
 class autogen_pypy_txt(AutoGenFile):
     PATH = 'hpy/tools/autogen/autogen_pypy.txt'
-    LANGUAGE = 'txt' # to avoid insering the disclaimer
+    LANGUAGE = 'txt' # to avoid inserting the disclaimer
 
     def generate(self):
         lines = []

setup.py

@@ -28,7 +28,7 @@
         # this seems to be a python which does not support hpy
         msg += 'This python implementation does not seem to support hpy:\n'
         msg += '(built-in module _hpy_universal not found).\n'
-        msg += 'Please contact your vendor for more informations.'
+        msg += 'Please contact your vendor for more information.'
     sys.exit(msg)
 
 

test/support.py

@@ -293,7 +293,7 @@ def compile_module(self, main_src, ExtensionTemplate=None, name='mytest', extra_
             compile_args = [
                 '/Od',
                 '/WX',               # turn warnings into errors (all, for now)
-                # '/Wall',           # this is too aggresive, makes windows itself fail
+                # '/Wall',           # this is too aggressive, makes windows itself fail
                 '/Zi',
                 '-D_CRT_SECURE_NO_WARNINGS', # something about _snprintf and _snprintf_s
                 '/FS',               # Since the tests run in parallel

test/test_cpy_compat.py

@@ -9,7 +9,7 @@ class TestCPythonCompatibility(HPyTest):
     # check e.g. after an HPy_Dup the refcnt is += 1. However, on PyPy they
     # are implemented in a completely different way which is unrelated to the
     # refcnt (this is the whole point of HPy, after all :)). So in many of the
-    # following ttests, checking the actual result of the function doesn't
+    # following tests, checking the actual result of the function doesn't
     # really make sens on PyPy. We still run the functions to ensure they do
     # not crash, though.
 

test/test_legacy_forbidden.py

@@ -7,7 +7,7 @@
 import pytest
 from .support import HPyTest, make_hpy_abi_fixture, ONLY_LINUX
 
-# this is not strictly correct, we should check whether the actualy compiler
+# this is not strictly correct, we should check whether the actual compiler
 # is GCC. But for the CI and most cases, it's enough to assume that if we are
 # on linux we are using GCC.
 #