Fix some typos and indents

cmakelang/command_tests/add_executable_tests.cmake

@@ -1,4 +1,4 @@
-# test: descriminator_hidden_behind_variable
+# test: discriminator_hidden_behind_variable
 # Ensure that argument's aren't sorted in the event that we can't infer the form
 # of the command.
 set(exetype ALIAS)

cmakelang/command_tests/add_library_tests.cmake

@@ -1,4 +1,4 @@
-# test: descriminator_hidden_behind_variable
+# test: discriminator_hidden_behind_variable
 set(libtype OBJECT)
 add_library(foobar ${libtype} ${alpha}.cc bar.cc baz.cc foo.cc)
 

cmakelang/configuration.py

@@ -49,7 +49,7 @@ class MarkupConfig(ConfigObject):
   explicit_trailing_pattern = FieldDescriptor(
       "#<",
       "If a comment line matches starts with this pattern then it is "
-      "explicitly a trailing comment for the preceeding argument. Default "
+      "explicitly a trailing comment for the preceding argument. Default "
       "is '#<'"
   )
   hashruler_min_length = FieldDescriptor(
@@ -259,15 +259,15 @@ class FormattingConfig(ConfigObject):
 
   dangle_parens = FieldDescriptor(
       False,
-      "If a statement is wrapped to more than one line, than dangle the"
+      "If a statement is wrapped to more than one line, then dangle the"
       " closing parenthesis on its own line."
   )
 
   dangle_align = FieldDescriptor(
       "prefix",
       "If the trailing parenthesis must be 'dangled' on its on line, then"
-      " align it to this reference: `prefix`: the start of the statement, "
-      " `prefix-indent`: the start of the statement, plus one indentation "
+      " align it to this reference: `prefix`: the start of the statement,"
+      " `prefix-indent`: the start of the statement, plus one indentation"
       " level, `child`: align to the column of the arguments",
       ["prefix", "prefix-indent", "child", "off"],
   )
@@ -316,8 +316,8 @@ class FormattingConfig(ConfigObject):
 
   enable_sort = FieldDescriptor(
       True,
-      "If true, the argument lists which are known to be sortable will be "
-      "sorted lexicographicall"
+      "If true, the argument lists which are known to be sortable will be"
+      " sorted lexicographically"
   )
 
   autosort = FieldDescriptor(
@@ -329,7 +329,7 @@ class FormattingConfig(ConfigObject):
   require_valid_layout = FieldDescriptor(
       False,
       "By default, if cmake-format cannot successfully fit everything into"
-      " the desired linewidth it will apply the last, most agressive"
+      " the desired linewidth it will apply the last, most aggressive"
       " attempt that it made. If this flag is True, however, cmake-format"
       " will print error, exit with non-zero status code, and write-out"
       " nothing"

cmakelang/doc/README.rst

@@ -168,7 +168,7 @@ An example short configuration file in python format is:
       # If true, separate function names from parentheses with a space
       separate_fn_name_with_space = False
 
-      # If a statement is wrapped to more than one line, than dangle the closing
+      # If a statement is wrapped to more than one line, then dangle the closing
       # parenthesis on its own line.
       dangle_parens = False
 

cmakelang/doc/changelog.rst

@@ -154,7 +154,7 @@ v0.6.9
 v0.6.8
 ------
 
-* Reduce packaging depependency version numbers
+* Reduce packaging dependency version numbers
 * Add build rules to generate variable and property pattern lists
 * Implement lint checks on assignment/use of variables that are "close" to
   builtins except for case.
@@ -287,7 +287,7 @@ v0.6.2
 * fix TOUCH_NOCREATE
 * copymode during --in-place
 * add --check command
-* supress spurious warnings in tests
+* suppress spurious warnings in tests
 * create add_custom_target parser
 * update add_custom_command parser with different forms
 * fix target form of install command
@@ -344,7 +344,7 @@ Significant refactor of the formatting logic.
 * ArgGroupNodes gain representation in the layout tree
 * Get rid of ``WrapAlgo``
 * Eliminate vertical/nest as separate decisions. Nesting is just the wrap
-  decision for StatementNode and KwargNode wheras vertical is the wrap
+  decision for StatementNode and KwargNode whereas vertical is the wrap
   decision for PargGroupnode and ArgGroupNode.
 * Replace ``algorithm_order`` with ``_layout_passes``
 * Get rid of ``default_accept_layout`` and move logic into a member function
@@ -425,7 +425,7 @@ v0.5.2
 * move ``add_library``, ``add_executable()`` and ``install()`` parsers to their
   own modules
 * don't infer sortability in ``add_library`` or ``add_executable()`` if the
-  descriminator token might be a cmake variable hiding the descriminator
+  discriminator token might be a cmake variable hiding the discriminator
   spelling
 * Split configuration options into different groups during dump and --help
 * Refactor long ``_reflow()`` implementations, splitting into methods for
@@ -450,7 +450,7 @@ v0.5.1
   children
 * Fix ``file(READ ...)`` and ``file(STRINGS ...)`` parser kwargs using set
   syntax instead of dict syntax
-* Fix agressive positional parser within conditional parser
+* Fix aggressive positional parser within conditional parser
 * Fix missing endif, endwhile in parsemap
 * Split parse functions out into separate modules for better organization
 * Add more sanity tests for ``file(...)``.

cmakelang/doc/configopts.rst

@@ -133,7 +133,7 @@ max_subgroups_hwrap
 A "subgroup" in this context is either a positional or keyword argument group
 within the current depth of the statement parse tree. If the number of
 "subgroups" at this depth is greater than ``max_subgroups_hwrap`` then
-hwrap-formatting is inadmissable and a vertical layout will be selected.
+hwrap-formatting is inadmissible and a vertical layout will be selected.
 
 The default value for this parameter is `2`.
 
@@ -201,10 +201,10 @@ The second statement has three argument groups:
 max_pargs_hwrap
 ===============
 
-This configuration parameter is relavent only to positional argument groups.
+This configuration parameter is relevant only to positional argument groups.
 A positional argument group is a list of "plain" arguments. If the number of
 arguments in the group is greater than this number, then then hwrap-formatting
-is inadmissable and a vertical layout will be selected.
+is inadmissible and a vertical layout will be selected.
 
 The default value for this parameter is 6
 
@@ -268,7 +268,7 @@ both.
 dangle_parens
 =============
 
-If a statement is wrapped to more than one line, than dangle the closing
+If a statement is wrapped to more than one line, then dangle the closing
 parenthesis on its own line. For example:
 
 .. code::
@@ -291,7 +291,7 @@ If the trailing parenthesis must be 'dangled' on it's on line, then align it
 to this reference. Options are:
 
 * ``prefix``: the start of the statement,
-* ``prefix-indent``: the start of the statement, plus one indentation  level
+* ``prefix-indent``: the start of the statement, plus one indentation level
 * ``child``: align to the column of the arguments
 
 For example:
@@ -414,7 +414,7 @@ require_valid_layout
 ====================
 
 By default, if cmake-format cannot successfully fit everything into the
-desired linewidth it will apply the last, most agressive attempt that it made.
+desired linewidth it will apply the last, most aggressive attempt that it made.
 If this flag is True, however, cmake-format will print error, exit with non-
 zero status code, and write-out nothing
 
@@ -538,7 +538,7 @@ but trailing whitespace will still be removed.
 explicit_trailing_pattern
 =========================
 
-If ``cmake-format`` encountes a comment within or at the very end of a
+If ``cmake-format`` encounters a comment within or at the very end of a
 statement it will try to determine whether or not that comment refers to
 a particular argument, and will format it accordingly. For example:
 
@@ -551,10 +551,10 @@ a particular argument, and will format it accordingly. For example:
     "BOZ" # multi value keywords
     ${ARGN})
 
-The rules for associating a comment with the preceeding argument depend on
+The rules for associating a comment with the preceding argument depend on
 how much (and what kinds) of whitespace separate them. Alternatively, if
 the comments match the ``explicit_trailing_pattern``, then they are associated
-with the preceeding argument regardless of the whitespace separating them.
+with the preceding argument regardless of the whitespace separating them.
 The format for this variable is a python regular expression matching prefix
 characters for such explicit trailing comments. The default value is ``#<``,
 such that the above example using explicit trailing comments would  be:

cmakelang/doc/format-algorithm.rst

@@ -7,7 +7,7 @@ Formatting Algorithm
 The formatter works by attempting to select an appropriate ``position`` and
 ``wrap`` (collectively referred to as a "layout") for each node in the layout
 tree. Positions are represented by ``(row, col)`` pairs and the wrap dictates
-how childen of that node are positioned.
+how children of that node are positioned.
 
 --------
 Wrapping
@@ -181,14 +181,14 @@ of it's children.
 2. If the token is the last token before a closing parenthesis, and the
    token plus the parenthesis would overflow the column limit, then insert a
    newline.
-3. If a token is preceeded by a line comment, then the token cannot be placed
+3. If a token is preceded by a line comment, then the token cannot be placed
    on the same line as the comment (or it will become part of the comment) so
    a newline is inserted between them.
 4. If a token is a line comment which is not associated with an argument (e.g.
    it is  a "free" comment at the current scope) then it will not be placed
-   on the same line as a preceeding argument token. If it was, then subsequent
+   on the same line as a preceding argument token. If it was, then subsequent
    parses would associate this comment with that argument. In such a case, a
-   newline is inserted between the preceeding argument and the line comment.
+   newline is inserted between the preceding argument and the line comment.
 5. If the node is an interior node, and one of it's children is internally
    wrapped (i.e. consumes more than two lines) then it will not be placed
    on the same line as another node. In such a case a newlines is inserted.

cmakelang/doc/parse-automatic.rst

@@ -64,7 +64,7 @@ can't really figure a pattern for when they are used and when  they are not.
 Ellipses
 ========
 
-Whether or not there is a space between an elipsis and the preceeding token
+Whether or not there is a space between an ellipsis and the preceding token
 seems to imply something about what is repeated.
 
 ::
@@ -79,7 +79,7 @@ seems to imply something about what is repeated.
                     [VERBATIM] [USES_TERMINAL])
 
 
-Note that the elipsis for "COMMAND" is inside the bracket above, but is
+Note that the ellipsis for "COMMAND" is inside the bracket above, but is
 outside the bracket here:
 
 ::
@@ -132,7 +132,7 @@ brackets.
       [<globbing-expressions>...])
 
 
-Manditory Sequence
+Mandatory Sequence
 ==================
 
 In this case the literal pattern is listed inside the mandatory group pattern
@@ -197,7 +197,7 @@ Conclusion
 
 After implementing a prototype parser and testing it on some of the above cases
 it is clear that the help text is not very consistent and is likely to be very
-challenging to get an implementation that works reliabily and knows when it
+challenging to get an implementation that works reliably and knows when it
 fails. For example:
 
 ::

cmakelang/lint/lint_util.py

@@ -54,7 +54,7 @@ def is_idstr(self, idstr):
   def suppress(self, lineno, idlist):
     """
     Given a list of lint ids, enable a suppression for each one which is not
-    already supressed. Return the list of new suppressions
+    already suppressed. Return the list of new suppressions
     """
     new_suppressions = []
     for idstr in idlist:

cmakelang/lint/lintdb.py

@@ -61,21 +61,21 @@ def get_database():
 "C0111", "Missing docstring on function or macro declaration", {
 "description": """\
 Used when a function or macro is defined without a documentation comment
-immediately preceeding it.
+immediately preceding it.
 
 This message belongs to the basic checker.
 """,
 "explain": """\
 So, you've written a some fancy function that makes it "easier" to declare build
 steps. Congratulations. You probably shouldn't have, but thats OK. Now that you
 did, how should people use it? What arguments does it take? What are the
-semantics of those arguements? You should include documentation in a comment
+semantics of those arguments? You should include documentation in a comment
 block prior to the function declaration with this information.
 """
 }), (
 "C0112", "Empty docstring on function or macro declaration", {
 "description": """\
-Used when a function or macro is preceeded by an empty comment string, rather
+Used when a function or macro is preceded by an empty comment string, rather
 that one with useful documentation.
 
 This message belongs to the basic checker.
@@ -88,20 +88,20 @@ def get_database():
 }), (
 "C0113", "Missing {:s} in statement which allows it", {
 }), (
-"C0114", "Form descriminator hidden behind variable dereference", {
+"C0114", "Form discriminator hidden behind variable dereference", {
 "description": """\
-Used when a keyword used to descriminate betwen different forms of a command is
+Used when a keyword used to discriminate between different forms of a command is
 hidden behind a variable dereference.
 
 This message is implemented by individual command checkers.
 """,
 "explain": """\
 Some cmake commands have very different behavior depending on the presence of
 a particular keyword (see e.g. the `file` command). And because cmake is a
-macro languge that keyword can actually be held inside a variable. Thus the
+macro language that keyword can actually be held inside a variable. Thus the
 keyword might not actually be visible to cmake-lint (or humans). In general
 there is no reason to do this and it really hurts readability since different
-descriminator keywords yield essentially different commands.
+discriminator keywords yield essentially different commands.
 """
 }), (
 "C0201", "Consider replacing custom parser logic with cmake_parse_arguments", {
@@ -176,7 +176,7 @@ def get_database():
 Used when an unrecognized pragma is encountered.
 """,
 "explain": """\
-cmake-lint allows for some inline comments to supress warnings (among other
+cmake-lint allows for some inline comments to suppress warnings (among other
 things). This lint is emitted if a bad option key is provided in such a pragma
 """
 }), (
@@ -188,7 +188,7 @@ def get_database():
 This message belongs to the basic checker.
 """,
 "explain": """\
-cmake-lint allows for some inline comments to supress warnings (among other
+cmake-lint allows for some inline comments to suppress warnings (among other
 things). This lint is emitted if a bad option is provided to one of these
 pragmas.
 """
@@ -227,10 +227,10 @@ def get_database():
 }), (
 "E1125", "Missing required keyword argument {:s}", {
 }), (
-"E1126", "Invalid form descriminator", {
+"E1126", "Invalid form discriminator", {
 "description": """
-Used when a keyword used to descriminate between different command forms is
-ommitted.
+Used when a keyword used to discriminate between different command forms is
+omitted.
 """
 }), (
 "R0911", "Too many return statements {:d}/{:d}", {

cmakelang/lint/test/lint_tests.cmake

@@ -84,15 +84,15 @@ install(
 # expect: E1120
 add_custom_command()
 
-# test: add-custom-command-hidden-descriminator
+# test: add-custom-command-hidden-discriminator
 # expect: C0114
 set(_form TARGET PRE_BUILD)
 add_custom_command(
   ${form}
   COMMAND echo "hello"
   COMMENT "echo hello")
 
-# test: add-custom-command-invalid-descriminator
+# test: add-custom-command-invalid-discriminator
 # expect: E1126
 add_custom_command(
   TARGRET PRE_BUILD
@@ -107,12 +107,12 @@ add_custom_command(OUTPUT foo)
 # expect: E1120
 file()
 
-# test: file-hidden-descriminator
+# test: file-hidden-discriminator
 # expect: C0114
 set(_form TOUCH)
 file(${form} foo.py)
 
-# test: file-invalid-descriminator
+# test: file-invalid-discriminator
 # expect: E1126
 file(TOUCHE foo.py)
 

cmakelang/parse/argument_nodes.py

@@ -348,7 +348,7 @@ def parse2(cls, ctx, tokens, spec, breakstack):
     tree.spec = spec
     nconsumed = 0
 
-    # Strip off any preceeding whitespace (note that in most cases this has
+    # Strip off any preceding whitespace (note that in most cases this has
     # already been done but in some cases (such ask kwarg subparser) where
     # it hasn't
     while tokens and tokens[0].type in WHITESPACE_TOKENS: