Fix typos across the codebase (#5573)

Thanks to the typos[1] tool!

Previously _PyCoMontoringData was ignored as part of #5064[2], which is
obviously the wrong name.  This PR changes it for the real
_PyCoMonitoringData name, but since it should be private that shouldn’t
affect any real user of the ffi crate.

[1] https://github.com/crate-ci/typos
[2] #5064

Author: linkmauve

CHANGELOG.md

@@ -2180,7 +2180,7 @@ default = ["extension-module"]
 
 ### Fixed
 
-- Fix undeterministic segfaults when creating many objects by kngwyu in [#281](https://github.com/PyO3/pyo3/pull/281)
+- Fix indeterministic segfaults when creating many objects by kngwyu in [#281](https://github.com/PyO3/pyo3/pull/281)
 
 ## [0.5.1] - 2018-11-24
 

Contributing.md

@@ -26,7 +26,7 @@ To work and develop PyO3, you need Python & Rust installed on your system.
 
 ### Testing, linting, etc. with nox
 
-[`Nox`][nox] is used to automate many of our CI tasks and can be used locally to handle verfication tasks as you code. We recommend running these actions via nox to make use of our prefered configuration options. You can install nox into your global python with pip: `pip install nox` or (recommended) with [`pipx`][pipx] `pip install pipx`, `pipx install nox`
+[`Nox`][nox] is used to automate many of our CI tasks and can be used locally to handle verification tasks as you code. We recommend running these actions via nox to make use of our preferred configuration options. You can install nox into your global python with pip: `pip install nox` or (recommended) with [`pipx`][pipx] `pip install pipx`, `pipx install nox`
 
 The main nox commands we have implemented are:
 

guide/src/migration.md

@@ -36,7 +36,7 @@ Most implementations can just add an elided lifetime to migrate.
 
 Additionally `FromPyObject` gained an associated type `Error`.
 This is the error type that can be used in case of a conversion error.
-During migration using `PyErr` is a good default, later a custom error type can be introduced to prevent unneccessary creation of Python exception objects and improved type safety.
+During migration using `PyErr` is a good default, later a custom error type can be introduced to prevent unnecessary creation of Python exception objects and improved type safety.
 
 Before:
 
@@ -101,7 +101,7 @@ where
 }
 ```
 
-Container types that need to create temporary Python references during extraction, for example extracing from a `PyList`, requires a stronger bound.
+Container types that need to create temporary Python references during extraction, for example extracting from a `PyList`, requires a stronger bound.
 For these the `FromPyObjectOwned` trait was introduced.
 It is automatically implemented for any type that implements `FromPyObject` and does not borrow from the input.
 It is intended to be used as a trait bound in these situations.
@@ -365,7 +365,7 @@ It may be preferable to instead use `std::sync::OnceLock` in combination with th
 
 Future PyO3 versions will likely add more traits and data structures to make working with free-threaded Python easier.
 
-Some features are unaccessible on the free-threaded build:
+Some features are inaccessible on the free-threaded build:
 
 - The `GILProtected` type, which relied on the GIL to expose synchronized access to inner contents
 - `PyList::get_item_unchecked`, which cannot soundly be used due to races between time-of-check and time-of-use

guide/src/module.md

@@ -19,7 +19,7 @@ mod my_extension {
     #[pymodule_export]
     use super::double; // The double function is made available from Python, works also with classes
 
-    #[pyfunction] // Inline definition of a pyfunction, also made availlable to Python
+    #[pyfunction] // Inline definition of a pyfunction, also made available to Python
     fn triple(x: usize) -> usize {
         x * 3
     }

pyo3-ffi/src/cpython/code.rs

@@ -28,7 +28,7 @@ use std::ptr::addr_of_mut;
 
 // skipped private _PyCoCached
 // skipped private _PyCoLineInstrumentationData
-// skipped private _PyCoMontoringData
+// skipped private _PyCoMonitoringData
 
 // skipped private _PyExecutorArray
 

pyo3-ffi/src/lib.rs

@@ -320,7 +320,7 @@
 #![doc = concat!("[manual_builds]: https://pyo3.rs/v", env!("CARGO_PKG_VERSION"), "/building-and-distribution.html#manual-builds \"Manual builds - Building and Distribution - PyO3 user guide\"")]
 //! [setuptools-rust]: https://github.com/PyO3/setuptools-rust "Setuptools plugin for Rust extensions"
 //! [PEP 384]: https://www.python.org/dev/peps/pep-0384 "PEP 384 -- Defining a Stable ABI"
-#![doc = concat!("[Features chapter of the guide]: https://pyo3.rs/v", env!("CARGO_PKG_VERSION"), "/features.html#features-reference \"Features eference - PyO3 user guide\"")]
+#![doc = concat!("[Features chapter of the guide]: https://pyo3.rs/v", env!("CARGO_PKG_VERSION"), "/features.html#features-reference \"Features reference - PyO3 user guide\"")]
 #![allow(
     missing_docs,
     non_camel_case_types,

src/call.rs

@@ -23,7 +23,7 @@ pub(crate) mod private {
 ///
 /// This trait is currently implemented for Rust tuple (up to a size of 12),
 /// [`Bound<'py, PyTuple>`] and [`Py<PyTuple>`]. Custom types that are
-/// convertable to `PyTuple` via `IntoPyObject` need to do so before passing it
+/// convertible to `PyTuple` via `IntoPyObject` need to do so before passing it
 /// to `call`.
 ///
 /// This trait is not intended to used by downstream crates directly. As such it
@@ -45,7 +45,7 @@ pub(crate) mod private {
 #[diagnostic::on_unimplemented(
     message = "`{Self}` cannot used as a Python `call` argument",
     note = "`PyCallArgs` is implemented for Rust tuples, `Bound<'py, PyTuple>` and `Py<PyTuple>`",
-    note = "if your type is convertable to `PyTuple` via `IntoPyObject`, call `<arg>.into_pyobject(py)` manually",
+    note = "if your type is convertible to `PyTuple` via `IntoPyObject`, call `<arg>.into_pyobject(py)` manually",
     note = "if you meant to pass the type as a single argument, wrap it in a 1-tuple, `(<arg>,)`"
 )]
 pub trait PyCallArgs<'py>: Sized + private::Sealed {

src/conversion.rs

@@ -334,7 +334,7 @@ impl<'py, T> IntoPyObjectExt<'py> for T where T: IntoPyObject<'py> {}
 /// ```
 /// This is basically what the derive macro above expands to.
 ///
-/// ## Manual implementation for types with lifetime paramaters
+/// ## Manual implementation for types with lifetime parameters
 /// For types that contain lifetimes, these lifetimes need to be bound to the corresponding
 /// [`FromPyObject`] lifetime. This is roughly how the extraction of a typed [`Bound`] is
 /// implemented within PyO3.

src/impl_/extract_argument.rs

@@ -531,7 +531,7 @@ impl FunctionDescription {
                 if let Some(i) = self.find_keyword_parameter_in_positional(kwarg_name) {
                     if i < self.positional_only_parameters {
                         // If accepting **kwargs, then it's allowed for the name of the
-                        // kwarg to conflict with a postional-only argument - the value
+                        // kwarg to conflict with a positional-only argument - the value
                         // will go into **kwargs anyway.
                         if K::handle_varkeyword(varkeywords, kwarg_name_py, value, self).is_err() {
                             positional_only_keyword_arguments.push(kwarg_name_owned);

src/instance.rs

@@ -925,7 +925,7 @@ impl<'py, T> BoundObject<'py, T> for Bound<'py, T> {
 ///
 /// Some Python C APIs also return "borrowed" pointers, which need to be increfd by the caller to
 /// keep them alive. This can also be modelled using [`Borrowed`]. However with free-threading these
-/// APIs are gradually replaced, because in absense of the GIL it is very hard to guarantee that the
+/// APIs are gradually replaced, because in absence of the GIL it is very hard to guarantee that the
 /// referred to object is not deallocated between receiving the pointer and incrementing the
 /// reference count. When possible APIs which return a "strong" reference (modelled by [`Bound`])
 /// should be using instead and otherwise great care needs to be taken to ensure safety.