diff --git a/clang-tools-extra/docs/clang-tidy/Contributing.rst b/clang-tools-extra/docs/clang-tidy/Contributing.rst index ff8b05ff263c..4f1df8d11444 100644 --- a/clang-tools-extra/docs/clang-tidy/Contributing.rst +++ b/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); diff --git a/clang/docs/ClangTransformerTutorial.rst b/clang/docs/ClangTransformerTutorial.rst index b07b83f80f17..e9b701203300 100644 --- a/clang/docs/ClangTransformerTutorial.rst +++ b/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")); diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst index 6614d036a014..18b05d2e58e6 100644 --- a/llvm/docs/DeveloperPolicy.rst +++ b/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 `. This section contains old information that needs to be updated. diff --git a/llvm/docs/GitHub.rst b/llvm/docs/GitHub.rst index 85766bfe94af..892b8abcc2d4 100644 --- a/llvm/docs/GitHub.rst +++ b/llvm/docs/GitHub.rst @@ -50,7 +50,7 @@ documentation refer to `GitHub's documentation `_ + add the `skip-precommit-approval `_ label to the PR. GitHub Tools diff --git a/llvm/docs/MyFirstTypoFix.rst b/llvm/docs/MyFirstTypoFix.rst index 733b3eac141f..5856615bee8b 100644 --- a/llvm/docs/MyFirstTypoFix.rst +++ b/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