docs: Fix typos in documentation and code comments

docs/extensions/built-in/dataclasses.md

@@ -25,7 +25,7 @@ def __init__(self, uid: int, name: str, capacity: int = 10, available: bool = Tr
 
 Additional metadata like `ClassVar`, the `init` and `kw_only` parameters, or the `KW_ONLY` sentinel are also recognized and will update the `__init__` method signature accordingly.
 
-**This extension is enabled by default.** It is always added last. If you need to give it a higher priority, you can explictly enable it to change its position in the list of extensions (it will run only once):
+**This extension is enabled by default.** It is always added last. If you need to give it a higher priority, you can explicitly enable it to change its position in the list of extensions (it will run only once):
 
 === "CLI"
     ```console

docs/guide/users/how-to/set-docstring-styles.md

@@ -1,6 +1,6 @@
 # Setting the right docstring style for every docstring
 
-Griffe attaches the specified docstring style and parsing options to each object in the tree of the package(s) you load. If your package(s) use several docstring styles, some of these objects will have the wrong style attached to them. This is problematic because other Griffe extensions rely on this attached style to parse docstrings and modify them. We plan to alleviate this limitation in the future (see [issue-340](https://github.com/mkdocstrings/griffe/issues/340)), but the most robust thing you can do is to make sure each object has the *right style* attached, as easly as possible, so that other extensions can work without issue.
+Griffe attaches the specified docstring style and parsing options to each object in the tree of the package(s) you load. If your package(s) use several docstring styles, some of these objects will have the wrong style attached to them. This is problematic because other Griffe extensions rely on this attached style to parse docstrings and modify them. We plan to alleviate this limitation in the future (see [issue-340](https://github.com/mkdocstrings/griffe/issues/340)), but the most robust thing you can do is to make sure each object has the *right style* attached, as easily as possible, so that other extensions can work without issue.
 
 There are currently two ways to make sure objects have the right docstring style attached as early as possible:
 

docs/guide/users/how-to/support-decorators.md

@@ -25,7 +25,7 @@ import griffe
 
 
 class MyDecorator(griffe.Extension):
-    """An extension to suport my decorator."""
+    """An extension to support my decorator."""
 ```
 
 Now we can declare the [`on_instance`][griffe.Extension.on_instance] hook, which receives any kind of Griffe object ([`Module`][griffe.Module], [`Class`][griffe.Class], [`Function`][griffe.Function], [`Attribute`][griffe.Attribute], [`TypeAlias`][griffe.TypeAlias]), or we could use a kind-specific hook such as [`on_module_instance`][griffe.Extension.on_module_instance], [`on_class_instance`][griffe.Extension.on_class_instance], [`on_function_instance`][griffe.Extension.on_function_instance], [`on_attribute_instance`][griffe.Extension.on_attribute_instance] and [`on_type_alias_instance`][griffe.Extension.on_type_alias_instance]. For example, if you know your decorator is only ever used on class declarations, it would make sense to use `on_class_instance`.
@@ -37,7 +37,7 @@ import griffe
 
 
 class MyDecorator(griffe.Extension):
-    """An extension to suport my decorator."""
+    """An extension to support my decorator."""
 
     def on_function_instance(self, *, func: griffe.Function, **kwargs) -> None:
         ...
@@ -50,7 +50,7 @@ import griffe
 
 
 class MyDecorator(griffe.Extension):
-    """An extension to suport my decorator."""
+    """An extension to support my decorator."""
 
     def on_function_instance(self, *, func: griffe.Function, **kwargs) -> None:
         for decorator in func.decorators:

docs/guide/users/navigating.md

@@ -89,21 +89,21 @@ To access an object's members, there are a few options:
 
 The same way members are accessed, they can also be set:
 
-- Dictionary-like item assignment: `markdown["thing"] = ...`, also supporting dotted-paths and string tuples. This will (re)assign only regular members: inherited members (classes only) are re-computed everytime they are accessed.
+- Dictionary-like item assignment: `markdown["thing"] = ...`, also supporting dotted-paths and string tuples. This will (re)assign only regular members: inherited members (classes only) are re-computed every time they are accessed.
 - Safer method for extensions: `markdown.set_member("thing", ...)`, also supporting dotted-paths and string tuples.
 - Regular member assignment: `markdown.members["thing"] = ...`. **This is not recommended, as the assigned member's `parent` attribute will not be automatically updated.**
 
 ...and deleted:
 
-- Dictionary-like item deletion: `del markdown["thing"]`, also supporting dotted-paths and string tuples. This will delete only regular members: inherited members (classes only) are re-computed everytime they are accessed.
+- Dictionary-like item deletion: `del markdown["thing"]`, also supporting dotted-paths and string tuples. This will delete only regular members: inherited members (classes only) are re-computed every time they are accessed.
 - Safer method for extensions: `markdown.del_member("thing")`, also supporting dotted-paths and string tuples.
 - Regular member deletion: `del markdown.members["thing"]`. **This is not recommended, as the [`aliases`][griffe.Object.aliases] attribute of other objects in the tree will not be automatically updated.**
 
 ### Inherited members
 
 Griffe supports class inheritance, both when visiting and inspecting modules.
 
-To access members of a class that are inherited from base classes, use the [`inherited_members`][griffe.Object.inherited_members] attribute. Everytime you access inherited members, the base classes of the given class will be resolved, then the MRO (Method Resolution Order) will be computed for these base classes, and a dictionary of inherited members will be built. Make sure to store the result in a variable to avoid re-computing it everytime (you are responsible for the caching part). Also make sure to only access `inherited_members` once everything is loaded by Griffe, to avoid computing things too early. Don't try to access inherited members in extensions, while visiting or inspecting modules.
+To access members of a class that are inherited from base classes, use the [`inherited_members`][griffe.Object.inherited_members] attribute. Every time you access inherited members, the base classes of the given class will be resolved, then the MRO (Method Resolution Order) will be computed for these base classes, and a dictionary of inherited members will be built. Make sure to store the result in a variable to avoid re-computing it every time (you are responsible for the caching part). Also make sure to only access `inherited_members` once everything is loaded by Griffe, to avoid computing things too early. Don't try to access inherited members in extensions, while visiting or inspecting modules.
 
 Inherited members are aliases that point at the corresponding members in parent classes. These aliases will have their [`inherited`][griffe.Alias.inherited] attribute set to true.
 

packages/griffelib/src/griffe/_internal/expressions.py

@@ -1147,7 +1147,7 @@ def iterate(self, *, flat: bool = True) -> Iterator[str | Expr]:
     ExprVarKeyword: lambda _: _OperatorPrecedence.STARRED,
     ExprYield: lambda _: _OperatorPrecedence.YIELD,
     ExprYieldFrom: lambda _: _OperatorPrecedence.YIELD,
-    # These are not standalone, they appear in specific contexts where precendence is not a concern.
+    # These are not standalone, they appear in specific contexts where precedence is not a concern.
     # NOTE: `for ... in ... if` part, not the whole `[...]`.
     ExprComprehension: lambda _: _OperatorPrecedence.NONE,
     ExprExtSlice: lambda _: _OperatorPrecedence.NONE,