Fix typos (#267)

docs/Hacking.md

@@ -34,7 +34,7 @@ See [Testing](Testing.md) for more details on the test framework.
 Note that it can be handy to look at the project files output by the tests
 to diagnose problems. The easiest way to do that is by kindly asking the
 test driver to leave the temporary directories it creates in-place.
-This is done by setting the enviroment variable "PRESERVE", e.g.
+This is done by setting the environment variable "PRESERVE", e.g.
 
 ```
 set PRESERVE=all # On Windows

docs/LanguageSpecification.md

@@ -157,7 +157,7 @@ have structural meaning for target definitions:
 | `all_dependent_settings` | A dictionary of settings to be applied to all dependents of the target, transitively. This includes direct dependents and the entire set of their dependents, and so on. This section may contain anything found within a `target` dictionary, except `configurations`, `target_name`, and `type` sections. Compare `direct_dependent_settings` and `link_settings`. |
 | `configurations` | A list of dictionaries defining build configurations for the target. See the "Configurations" section below. |
 | `copies` | A list of copy actions to perform. See the "Copies" section below. |
-| `defines` | A list of preprocesor definitions to be passed on the command line to the C/C++ compiler (via `-D` or `/D` options). |
+| `defines` | A list of preprocessor definitions to be passed on the command line to the C/C++ compiler (via `-D` or `/D` options). |
 | `dependencies` | A list of targets on which this target depends. Targets in other `.gyp` files are specified as `../path/to/other.gyp:target_we_want`. |
 | `direct_dependent_settings` | A dictionary of settings to be applied to other targets that depend on this target. These settings will only be applied to direct dependents. This section may contain anything found within a `target` dictionary, except `configurations`, `target_name`, and `type` sections. Compare with `all_dependent_settings` and `link_settings`. |
 | `include_dirs` | A list of include directories to be passed on the command line to the C/C++ compiler (via `-I` or `/I` options). |
@@ -208,8 +208,8 @@ Configuration dictionaries may also contain these elements:
 
 Conditionals may appear within any dictionary in a `.gyp` file. There
 are two tpes of conditionals, which differ only in the timing of their
-processing. `conditons` sections are processed shortly after loading
-`.gyp` files, and `target_conditons` sections are processed after all
+processing. `conditions` sections are processed shortly after loading
+`.gyp` files, and `target_conditions` sections are processed after all
 dependencies have been computed.
 
 A conditional section is introduced with a `conditions` or

docs/Testing.md

@@ -392,15 +392,15 @@ fails the test if it does.
 
 Verifies that the output string contains all of the "lines" in the specified
 list of lines. In practice, the lines can be any substring and need not be
-`\n`-terminaed lines per se. If any line is missing, the test fails.
+`\n`-terminated lines per se. If any line is missing, the test fails.
 
 ```
  test.must_not_contain_any_lines(output, lines)
 ```
 
 Verifies that the output string does _not_ contain any of the "lines" in the
 specified list of lines. In practice, the lines can be any substring and need
-not be `\n`-terminaed lines per se. If any line exists in the output string,
+not be `\n`-terminated lines per se. If any line exists in the output string,
 the test fails.
 
 ```
@@ -409,7 +409,7 @@ the test fails.
 
 Verifies that the output string contains at least one of the "lines" in the
 specified list of lines. In practice, the lines can be any substring and need
-not be `\n`-terminaed lines per se. If none of the specified lines is present,
+not be `\n`-terminated lines per se. If none of the specified lines is present,
 the test fails.
 
 ### Reading file contents

docs/UserDocumentation.md

@@ -104,7 +104,7 @@ describing all the information necessary to build the target.
 
 `'conditions'`: A list of condition specifications that can modify the
 contents of the items in the global dictionary defined by this `.gyp`
-file based on the values of different variablwes. As implied by the
+file based on the values of different variables. As implied by the
 above example, the most common use of a `conditions` section in the
 top-level dictionary is to add platform-specific targets to the
 `targets` list.
@@ -375,7 +375,7 @@ If your platform-specific file does not contain a
 already in the `conditions` for the target), and you can't change the
 file name, there are two patterns that can be used.
 
-**Prefererred**: Add the file to the `sources` list of the appropriate
+**Preferred**: Add the file to the `sources` list of the appropriate
 dictionary within the `targets` list. Add an appropriate `conditions`
 section to exclude the specific files name:
 
@@ -807,7 +807,7 @@ directory:
 ```
 
 Adding a library often involves updating multiple `.gyp` files, adding
-the target to the approprate `.gyp` file (possibly a newly-added `.gyp`
+the target to the appropriate `.gyp` file (possibly a newly-added `.gyp`
 file), and updating targets in the other `.gyp` files that depend on
 (link with) the new library.
 
@@ -858,7 +858,7 @@ because of those settings' being listed in the
 `direct_dependent_settings` block.
 
 Note that these settings will likely need to be replicated in the
-settings for the library target itsef, so that the library will build
+settings for the library target itself, so that the library will build
 with the same options. This does not prevent the target from defining
 additional options for its "internal" use when compiling its own source
 files. (In the above example, these are the `LOCAL_DEFINE_FOR_LIBBAR`

pylib/gyp/generator/analyzer.py

@@ -699,7 +699,7 @@ def find_matching_test_target_names(self):
  ) & set(self._root_targets)
  if matching_test_targets_contains_all:
  # Remove any of the targets for all that were not explicitly supplied,
- # 'all' is subsequentely added to the matching names below.
+ # 'all' is subsequently added to the matching names below.
  matching_test_targets = list(
  set(matching_test_targets) & set(test_targets_no_all)
  )

pylib/gyp/generator/android.py

@@ -769,7 +769,7 @@ def ExtractIncludesFromCFlags(self, cflags):
  Args:
  cflags: A list of compiler flags, which may be mixed with "-I.."
  Returns:
- A tuple of lists: (clean_clfags, include_paths). "-I.." is trimmed.
+ A tuple of lists: (clean_cflags, include_paths). "-I.." is trimmed.
  """
  clean_cflags = []
  include_paths = []

pylib/gyp/generator/cmake.py

@@ -251,7 +251,7 @@ def WriteActions(target_name, actions, extra_sources, extra_deps, path_to_gyp, o
  target_name: the name of the CMake target being generated.
  actions: the Gyp 'actions' dict for this target.
  extra_sources: [(<cmake_src>, <src>)] to append with generated source files.
- extra_deps: [<cmake_taget>] to append with generated targets.
+ extra_deps: [<cmake_target>] to append with generated targets.
  path_to_gyp: relative path from CMakeLists.txt being generated to
  the Gyp file in which the target being generated is defined.
  """
@@ -340,7 +340,7 @@ def WriteRules(target_name, rules, extra_sources, extra_deps, path_to_gyp, outpu
  target_name: the name of the CMake target being generated.
  actions: the Gyp 'actions' dict for this target.
  extra_sources: [(<cmake_src>, <src>)] to append with generated source files.
- extra_deps: [<cmake_taget>] to append with generated targets.
+ extra_deps: [<cmake_target>] to append with generated targets.
  path_to_gyp: relative path from CMakeLists.txt being generated to
  the Gyp file in which the target being generated is defined.
  """
@@ -457,7 +457,7 @@ def WriteCopies(target_name, copies, extra_deps, path_to_gyp, output):
  Args:
  target_name: the name of the CMake target being generated.
  actions: the Gyp 'actions' dict for this target.
- extra_deps: [<cmake_taget>] to append with generated targets.
+ extra_deps: [<cmake_target>] to append with generated targets.
  path_to_gyp: relative path from CMakeLists.txt being generated to
  the Gyp file in which the target being generated is defined.
  """
@@ -603,7 +603,7 @@ class CMakeNamer:
  """
 
  def __init__(self, target_list):
- self.cmake_target_base_names_conficting = set()
+ self.cmake_target_base_names_conflicting = set()
 
  cmake_target_base_names_seen = set()
  for qualified_target in target_list:
@@ -612,11 +612,11 @@ def __init__(self, target_list):
  if cmake_target_base_name not in cmake_target_base_names_seen:
  cmake_target_base_names_seen.add(cmake_target_base_name)
  else:
- self.cmake_target_base_names_conficting.add(cmake_target_base_name)
+ self.cmake_target_base_names_conflicting.add(cmake_target_base_name)
 
  def CreateCMakeTargetName(self, qualified_target):
  base_name = CreateCMakeTargetBaseName(qualified_target)
- if base_name in self.cmake_target_base_names_conficting:
+ if base_name in self.cmake_target_base_names_conflicting:
  return CreateCMakeTargetFullName(qualified_target)
  return base_name
 

pylib/gyp/generator/make.py

@@ -1834,7 +1834,7 @@ def WriteTarget(
  # Since this target depends on binary and resources which are in
  # nested subfolders, the framework directory will be older than
  # its dependencies usually. To prevent this rule from executing
- # on every build (expensive, especially with postbuilds), expliclity
+ # on every build (expensive, especially with postbuilds), explicitly
  # update the time on the framework directory.
  self.WriteLn("\t@touch -c %s" % QuoteSpaces(self.output))
 

pylib/gyp/generator/msvs.py

@@ -3275,7 +3275,7 @@ def _GetMSBuildPropertyGroup(spec, label, properties):
  num_configurations = len(spec["configurations"])
 
  def GetEdges(node):
- # Use a definition of edges such that user_of_variable -> used_varible.
+ # Use a definition of edges such that user_of_variable -> used_variable.
  # This happens to be easier in this case, since a variable's
  # definition contains all variables it references in a single string.
  edges = set()

pylib/gyp/generator/xcode.py

@@ -959,7 +959,7 @@ def GenerateOutput(target_list, target_dicts, data, params):
  # would-be additional inputs are newer than the output. Modifying
  # the source tree - even just modification times - feels dirty.
  # 6564240 Xcode "custom script" build rules always dump all environment
- # variables. This is a low-prioroty problem and is not a
+ # variables. This is a low-priority problem and is not a
  # show-stopper.
  rules_by_ext = {}
  for rule in spec_rules:

pylib/gyp/input.py

@@ -1240,7 +1240,7 @@ def ProcessConditionsInDict(the_dict, phase, variables, build_file):
  )
 
  if merge_dict is not None:
- # Expand variables and nested conditinals in the merge_dict before
+ # Expand variables and nested conditionals in the merge_dict before
  # merging it.
  ProcessVariablesAndConditionsInDict(
  merge_dict, phase, variables, build_file

pylib/gyp/xcode_emulation.py

@@ -1861,7 +1861,7 @@ def _TopologicallySortedEnvVarKeys(env):
  regex = re.compile(r"\$\{([a-zA-Z0-9\-_]+)\}")
 
  def GetEdges(node):
- # Use a definition of edges such that user_of_variable -> used_varible.
+ # Use a definition of edges such that user_of_variable -> used_variable.
  # This happens to be easier in this case, since a variable's
  # definition contains all variables it references in a single string.
  # We can then reverse the result of the topological sort at the end.

pylib/gyp/xcodeproj_file.py

@@ -74,7 +74,7 @@
 PBXBuildFile appears extraneous, but there's actually one reason for this:
 file-specific compiler flags are added to the PBXBuildFile object so as to
 allow a single file to be a member of multiple targets while having distinct
-compiler flags for each. These flags can be modified in the Xcode applciation
+compiler flags for each. These flags can be modified in the Xcode application
 in the "Build" tab of a File Info window.
 
 When a project is open in the Xcode application, Xcode will rewrite it. As
@@ -662,7 +662,7 @@ def _XCKVPrint(self, file, tabs, key, value):
 
  tabs is an int identifying the indentation level. If the class'
  _should_print_single_line variable is True, tabs is ignored and the
- key-value pair will be followed by a space insead of a newline.
+ key-value pair will be followed by a space instead of a newline.
  """
 
  if self._should_print_single_line:
@@ -2994,7 +2994,7 @@ def AddOrGetProjectReference(self, other_pbxproject):
  key=lambda x: x["ProjectRef"].Name().lower()
  )
  else:
- # The link already exists. Pull out the relevnt data.
+ # The link already exists. Pull out the relevant data.
  project_ref_dict = self._other_pbxprojects[other_pbxproject]
  product_group = project_ref_dict["ProductGroup"]
  project_ref = project_ref_dict["ProjectRef"]

pylib/packaging/metadata.py

@@ -145,7 +145,7 @@ class RawMetadata(TypedDict, total=False):
 
  # Metadata 2.3 - PEP 685
  # No new fields were added in PEP 685, just some edge case were
- # tightened up to provide better interoptability.
+ # tightened up to provide better interoperability.
 
 
 _STRING_FIELDS = {
@@ -206,10 +206,10 @@ def _parse_project_urls(data: List[str]) -> Dict[str, str]:
  # be the missing value, then they'd have multiple '' values that
  # overwrite each other in a accumulating dict.
  #
- # The other potentional issue is that it's possible to have the
+ # The other potential issue is that it's possible to have the
  # same label multiple times in the metadata, with no solid "right"
  # answer with what to do in that case. As such, we'll do the only
- # thing we can, which is treat the field as unparseable and add it
+ # thing we can, which is treat the field as unparsable and add it
  # to our list of unparsed fields.
  parts = [p.strip() for p in pair.split(",", 1)]
  parts.extend([""] * (max(0, 2 - len(parts)))) # Ensure 2 items
@@ -222,8 +222,8 @@ def _parse_project_urls(data: List[str]) -> Dict[str, str]:
  label, url = parts
  if label in urls:
  # The label already exists in our set of urls, so this field
- # is unparseable, and we can just add the whole thing to our
- # unparseable data and stop processing it.
+ # is unparsable, and we can just add the whole thing to our
+ # unparsable data and stop processing it.
  raise KeyError("duplicate labels in project urls")
  urls[label] = url
 
@@ -433,7 +433,7 @@ def parse_email(data: Union[bytes, str]) -> Tuple[RawMetadata, Dict[str, List[st
  except KeyError:
  unparsed[name] = value
  # Nothing that we've done has managed to parse this, so it'll just
- # throw it in our unparseable data and move on.
+ # throw it in our unparsable data and move on.
  else:
  unparsed[name] = value
 
@@ -450,7 +450,7 @@ def parse_email(data: Union[bytes, str]) -> Tuple[RawMetadata, Dict[str, List[st
  else:
  if payload:
  # Check to see if we've already got a description, if so then both
- # it, and this body move to unparseable.
+ # it, and this body move to unparsable.
  if "description" in raw:
  description_header = cast(str, raw.pop("description"))
  unparsed.setdefault("description", []).extend(

tools/pretty_vcproj.py

@@ -207,7 +207,7 @@ def CleanupVcproj(node):
  node.appendChild(new_node)
 
 
-def GetConfiguationNodes(vcproj):
+def GetConfigurationNodes(vcproj):
  # TODO(nsylvain): Find a better way to navigate the xml.
  nodes = []
  for node in vcproj.childNodes:
@@ -307,7 +307,7 @@ def main(argv):
 
  # First thing we need to do is find the Configuration Node and merge them
  # with the vsprops they include.
- for configuration_node in GetConfiguationNodes(dom.documentElement):
+ for configuration_node in GetConfigurationNodes(dom.documentElement):
  # Get the property sheets associated with this configuration.
  vsprops = configuration_node.getAttribute("InheritedPropertySheets")