Fix typos in comments and symbols naming (#7318)

Author: rex4539

Documentation/Design/PackageManagerCommunityProposal.md

@@ -1,6 +1,6 @@
 # Swift Package Manager Community Proposal
 
-> **PLEASE NOTE** This document represents the initial proposal for Swift Package Manger, and is provided for historical purposes only. It does not represent the current state or future direction of the project. For current documentation, see the main Swift Package Manager [documentation](../README.md).
+> **PLEASE NOTE** This document represents the initial proposal for Swift Package Manager, and is provided for historical purposes only. It does not represent the current state or future direction of the project. For current documentation, see the main Swift Package Manager [documentation](../README.md).
 
 --- 
 

Documentation/Design/SwiftBasedManifestFormat.md

@@ -1,6 +1,6 @@
 # Swift-based Manifest Format
 
-> **PLEASE NOTE** This document represents the initial proposal for Swift Package Manger, and is provided for historical purposes only. It does not represent the current state or future direction of the project. For current documentation, see the main Swift Package Manager [documentation](../README.md).
+> **PLEASE NOTE** This document represents the initial proposal for Swift Package Manager, and is provided for historical purposes only. It does not represent the current state or future direction of the project. For current documentation, see the main Swift Package Manager [documentation](../README.md).
 
 ## Purpose
 
@@ -122,7 +122,7 @@ It is important to note that even when using this feature, package manifest stil
 
 The package definition format being written in Swift is problematic for tools that wish to perform automatic updates to the file (for example, in response to a user action, or to bind to a user interface), or for situations where dealing with executable code is problematic.
 
-To that end, the declarative package specification portion of the file is "Swift" in the same sense that "JSON is Javascript". The syntax itself is valid, executable, Swift but the tools that process it will only accept a restricted, declarative, subset of Swift which can be statically evaluated, and which can be unambiguously, automatically rewritten by editing tools. We do not intend to define a "standard" syntax for "Swift Object Notation", but we intend to accept a natural restriction of the language which only accepts literal expressions. We do intend to allow the restricted subset to take full advantage of Swift's rich type inference and literal convertable design to allow for a succinct, readable, and yet expressive syntax.
+To that end, the declarative package specification portion of the file is "Swift" in the same sense that "JSON is Javascript". The syntax itself is valid, executable, Swift but the tools that process it will only accept a restricted, declarative, subset of Swift which can be statically evaluated, and which can be unambiguously, automatically rewritten by editing tools. We do not intend to define a "standard" syntax for "Swift Object Notation", but we intend to accept a natural restriction of the language which only accepts literal expressions. We do intend to allow the restricted subset to take full advantage of Swift's rich type inference and literal convertible design to allow for a succinct, readable, and yet expressive syntax.
 
 The customization section above will *not* be written in this syntax. Instead, the customization section will be clearly demarcated in the file. The leading file section up to the first '// MARK:' will be processed as part of the restricted declarative specification. All subsequent code **must be** honored by tools which only need to consume the output of the specification, and **should be** displayed by tools which present an editor view of the manifest, but **should not** be automatically modified. The semantics of the APIs will be specifically designed to accommodate the expected use case of editor support for the primary data with custom project-specific logic for special cases.
 

Documentation/ModuleAliasing.md

@@ -121,7 +121,7 @@ If more aliases need to be defined, they can be added with a comma delimiter, pe
 
 ## Override Module Aliases
 
-If module alias values defined upstream are conflicting downstream, they can be overriden by chaining; add an entry to the `moduleAliases` parameter downstream using the conflicting alias value as a key and provide a unique value. 
+If module alias values defined upstream are conflicting downstream, they can be overridden by chaining; add an entry to the `moduleAliases` parameter downstream using the conflicting alias value as a key and provide a unique value. 
 
 To illustrate, the `swift-draw` and `swift-game` packages are modified to have the following dependencies and module aliases. 
 
@@ -190,7 +190,7 @@ To override it, the `App` manifest can define its own module aliases per below.
             ])
     ]
 ```
-The `Utils` module from package `a-utils` will be renamed as `DrawUtils`, and `Utils` from package `c-utils` will be renamed as `GameUtils`. Each overriden alias will be applied to all of the targets that depend on each module.
+The `Utils` module from package `a-utils` will be renamed as `DrawUtils`, and `Utils` from package `c-utils` will be renamed as `GameUtils`. Each overridden alias will be applied to all of the targets that depend on each module.
 
 ## Requirements
 

Documentation/PackageRegistry/PackageRegistryUsage.md

@@ -158,7 +158,7 @@ any package identifier (e.g., `mona.LinkedList`).
 One can control if/how SwiftPM should use registry in conjunction with 
 source control dependencies by setting one of these flags:
 - `--disable-scm-to-registry-transformation` (default): SwiftPM will not transform source control dependency to registry dependency. Source control dependency will be downloaded from its corresponding URL, while registry dependency will be resolved and downloaded using the configured registry (if any).
-- `--use-registry-identity-for-scm`: SwiftPM will look up source control dependencies in the registry and use their registry identity whenever possible to help deduplicate packages across the two origins. In other words, suppose `mona.LinkedList` is the package identifer for `https://github.com/mona/LinkedList`, then SwiftPM will treat both references in the dependency graph as the same package. 
+- `--use-registry-identity-for-scm`: SwiftPM will look up source control dependencies in the registry and use their registry identity whenever possible to help deduplicate packages across the two origins. In other words, suppose `mona.LinkedList` is the package identifier for `https://github.com/mona/LinkedList`, then SwiftPM will treat both references in the dependency graph as the same package. 
 - `--replace-scm-with-registry`: SwiftPM will look up source control dependencies in the registry and use the registry to retrieve them instead of source control when possible. In other words, SwiftPM will attempt to download a source control dependency from the registry first, and fall back to cloning the source repository iff the dependency is not found in the registry.
 
 ## Dependency Download From Registry
@@ -183,7 +183,7 @@ or previous value, SwiftPM will fail the build. This can be
 tuned down from error to warning by setting the build option 
 `--resolver-fingerprint-checking` to `warn` (default is `strict`).
 
-Checkum TOFU is also done for manifests downloaded from registry. 
+Checksum TOFU is also done for manifests downloaded from registry. 
 
 ### Validating signed packages
 
@@ -456,7 +456,7 @@ $ swift package-registry set --scope foo https://local.example.com
 $ swift package-registry set --scope foo --global https://global.example.com  
 ```
 
-To remove a registry assignement, use the `swift package-registry unset` subcommand.
+To remove a registry assignment, use the `swift package-registry unset` subcommand.
   
 ### Security configuration
 

Documentation/PackageSecurity.md

@@ -38,7 +38,7 @@ the build option `--resolver-fingerprint-checking` to `warn` (default is `strict
 
 Note that in case of registry packages, a package version's fingerprint
 must be consistent across registries or else there will be a TOFU failure.
-As an example, suppose a package version was originially downloaded from
+As an example, suppose a package version was originally downloaded from
 registry A and the source archive checksum was saved as the fingerprint. Later
 the package version is downloaded again but from registry B and has a different
 fingerprint. This would trigger a TOFU failure since the fingerprint should

Documentation/ReleaseNotes/5.4.md

@@ -27,6 +27,6 @@ All [Unicode line terminators](https://www.unicode.org/reports/tr14/) are now re
 
 Swift Package Manager now caches package dependency repositories on a per-user basis, which reduces the amount of network traffic and increases performance of dependency resolution for subsequent uses of the same package.
 
-The default location of the cache differs dependening on the platform, but can be controlled using the new `--cache-path` option. SwiftPM also creates a symbolic link at `~/.swiftpm` referencing the default cache location.
+The default location of the cache differs depending on the platform, but can be controlled using the new `--cache-path` option. SwiftPM also creates a symbolic link at `~/.swiftpm` referencing the default cache location.
 
 Compiled package manifests are also now cached on a per-user basis. This can be overridden using the new `--manifest-cache` option.

Documentation/ReleaseNotes/5.6.md

@@ -26,11 +26,11 @@ Dependency requirement enum calling convention is deprecated in favour of labele
 
 ### Other Improvements
 
-Location of configuration files (including mirror file) have changed to accomodate new features that require more robust configuration directories structure, such as SE-0292:
+Location of configuration files (including mirror file) have changed to accommodate new features that require more robust configuration directories structure, such as SE-0292:
 
 * `<project>/.swiftpm/config` (mirrors file) was moved to `<project>/.swiftpm/configuration/mirrors.json`. SwiftPM 5.6 will automatically copy the file from the old location to the new one and emit a warning to prompt the user to delete the file from the old location.
 * `~/.swiftpm/config/collections.json` (collections file) was moved to `~/.swiftpm/configuration/collections.json`. SwiftPM 5.6 will automatically copy the file from the old location to the new one and emit a warning to prompt the user to delete the file from the old location.
 
-To increase the security of packages, SwiftPM performs trust on first use (TOFU) validation. The fingerprint of a package is now being recorded when the package is first downloaded from a Git repository or package registry. Subsequent downloads must have fingerpints matching previous recorded values, otherwise it would result in build warnings or failures depending on settings.
+To increase the security of packages, SwiftPM performs trust on first use (TOFU) validation. The fingerprint of a package is now being recorded when the package is first downloaded from a Git repository or package registry. Subsequent downloads must have fingerprints matching previous recorded values, otherwise it would result in build warnings or failures depending on settings.
 
 Introduce a second version of `Package.resolved` file format which more accurately captures package identity.

Documentation/ReleaseNotes/5.8.md

@@ -12,7 +12,7 @@ In packages using tools version 5.8 or later, `Foundation` is no longer implicit
 
 SwiftPM now supports token authentication when interacting with a package registry. The `swift package-registry` command has two new subcommands `login` and `logout` as defined in [SE-0378](https://github.com/apple/swift-evolution/blob/main/proposals/0378-package-registry-auth.md) for adding/removing registry credentials.  
 
-## Other improvments
+## Other improvements
 
 Improved handling of offline behavior when a compatible cached version of a dependency exists on disk in either the per-package or shared cache. SwiftPM will check for network availability status to determine if it should attempt to update a checked version of a dependency, and when offline will use the cached version without an update.  
 

Documentation/Usage.md

@@ -187,7 +187,7 @@ let package = Package(
     name: "example",
     targets: [
         // systemLibrary is a special type of build target that wraps a system library
-        // in a target that other targets can require as their depencency.
+        // in a target that other targets can require as their dependency.
         .systemLibrary(
             name: "Clibgit",
             pkgConfig: "libgit2",
@@ -266,7 +266,7 @@ let package = Package(
         ),
 
         // systemLibrary is a special type of build target that wraps a system library
-        // in a target that other targets can require as their depencency.
+        // in a target that other targets can require as their dependency.
         .systemLibrary(
             name: "Clibgit",
             pkgConfig: "libgit2",
@@ -579,7 +579,7 @@ You can end editing a package using `unedit` command:
 This will remove the edited dependency from `Packages/` and put the originally
 resolved version back.
 
-This command fails if there are uncommited changes or changes which are not
+This command fails if there are uncommitted changes or changes which are not
 pushed to the remote repository. If you want to discard these changes and
 unedit, you can use the `--force` option:
 

Fixtures/Miscellaneous/CXX17CompilerCrash/v5_7/include/user_objects.h

@@ -89,7 +89,7 @@ class mjCError {
 // alternative specifications of frame orientation
 class mjCAlternative {
  public:
-  mjCAlternative();                               // constuctor
+  mjCAlternative();                               // constructor
   const char* Set(double* quat, double* inertia,  // set frame quat and diag. inertia
                   bool degree,                    //  angle format: degree/radian
                   const char* sequence);          //  euler sequence format: "xyz"