Fix some typos

Author: DeNiCoN

clang-tools-extra/docs/clang-tidy/Contributing.rst

@@ -331,7 +331,7 @@ a starting point for your test cases.  A rough outline of the process looks like
 - Issue the necessary diagnostics and fix-its in the ``check`` method.
 - Add the necessary ``CHECK-MESSAGES`` and ``CHECK-FIXES`` annotations to your
   test case to validate the diagnostics and fix-its.
-- Build the target ``check-clang-tool`` to confirm the test passes.
+- Build the target ``check-clang-tools`` to confirm the test passes.
 - Repeat the process until all aspects of your check are covered by tests.
 
 The quickest way to prototype your matcher is to use :program:`clang-query` to
@@ -519,8 +519,8 @@ the check implements and what the current values are (e.g. for the
   public:
     MyCheck(StringRef Name, ClangTidyContext *Context)
       : ClangTidyCheck(Name, Context),
-        SomeOption(Options.get("SomeOption1", -1U)),
-        SomeOption(Options.get("SomeOption2", "some default")) {}
+        SomeOption1(Options.get("SomeOption1", -1U)),
+        SomeOption2(Options.get("SomeOption2", "some default")) {}
 
     void storeOptions(ClangTidyOptions::OptionMap &Opts) override {
       Options.store(Opts, "SomeOption1", SomeOption1);

clang/docs/ClangTransformerTutorial.rst

@@ -70,7 +70,7 @@ can express this a Transformer rewrite rule:
 
 .. code-block:: c++
 
-   makeRule(functionDecl(hasName("MkX").bind("fun"),
+   makeRule(functionDecl(hasName("MkX")).bind("fun"),
 	    noopEdit(node("fun")),
 	    cat("The name ``MkX`` is not allowed for functions; please rename"));
 

clang/include/clang/Basic/Diagnostic.h

@@ -224,7 +224,7 @@ class DiagStorageAllocator {
 
 /// Concrete class used by the front-end to report problems and issues.
 ///
-/// This massages the diagnostics (e.g. handling things like "report warnings
+/// This messages the diagnostics (e.g. handling things like "report warnings
 /// as errors" and passes them off to the DiagnosticConsumer for reporting to
 /// the user. DiagnosticsEngine is tied to one translation unit and one
 /// SourceManager.

llvm/docs/DeveloperPolicy.rst

@@ -136,7 +136,7 @@ awareness of. For such changes, the following should be done:
 
 .. warning::
 
-  Phabricator is deprecated is available in read-only mode,
+  Phabricator is deprecated and is available in read-only mode,
   for new code contributions use :ref:`GitHub Pull Requests <github-reviews>`.
   This section contains old information that needs to be updated.
 

llvm/docs/GitHub.rst

@@ -50,7 +50,7 @@ documentation refer to `GitHub's documentation <https://docs.github.com/pull-req
 .. note::
    If you are using a Pull Request for purposes other than review
    (eg: precommit CI results, convenient web-based reverts, etc)
-   `skip-precommit-approval <https://github.com/llvm/llvm-project/labels?q=skip-precommit-approval>`_
+   add a `skip-precommit-approval <https://github.com/llvm/llvm-project/labels?q=skip-precommit-approval>`_
    label to the PR.
 
 GitHub Tools

llvm/docs/MyFirstTypoFix.rst

@@ -378,7 +378,7 @@ your branch with more commits and push to your GitHub fork of ``llvm-project``.
 It is best if you answer comments from the reviewer directly instead of expecting
 them to read through all the changes again.
 
-For example you might comment "I have done this." or "I was able to this part
+For example you might comment "I have done this." or "I was able to do this part
 but have a question about...".
 
 Review expectations