diff --git a/llvm/docs/CodingStandards.rst b/llvm/docs/CodingStandards.rst --- a/llvm/docs/CodingStandards.rst +++ b/llvm/docs/CodingStandards.rst @@ -77,7 +77,7 @@ possible. LLVM support libraries (for example, `ADT -`_) +`_) implement specialized data structures or functionality missing in the standard library. Such libraries are usually implemented in the ``llvm`` namespace and follow the expected standard interface, when there is one. diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst --- a/llvm/docs/DeveloperPolicy.rst +++ b/llvm/docs/DeveloperPolicy.rst @@ -80,7 +80,7 @@ When making a patch for review, the goal is to make it as easy for the reviewer to read it as possible. As such, we recommend that you: -#. Make your patch against git master, not a branch, and not an old version +#. Make your patch against git main, not a branch, and not an old version of LLVM. This makes it easy to apply the patch. For information on how to clone from git, please see the :ref:`Getting Started Guide `. @@ -146,7 +146,7 @@ responsibility of a code owner is to ensure that a commit to their area of the code is appropriately reviewed, either by themself or by someone else. The list of current code owners can be found in the file `CODE_OWNERS.TXT -`_ in the +`_ in the root of the LLVM source tree. Note that code ownership is completely different than reviewers: anyone can diff --git a/llvm/docs/FAQ.rst b/llvm/docs/FAQ.rst --- a/llvm/docs/FAQ.rst +++ b/llvm/docs/FAQ.rst @@ -13,7 +13,7 @@ ------------------------------------------------------------------- Yes. The modified source distribution must retain the copyright notice and follow the conditions listed in the `Apache License v2.0 with LLVM Exceptions -`_. +`_. Can I modify the LLVM source code and redistribute binaries or other tools based on it, without redistributing the source? diff --git a/llvm/docs/GettingStarted.rst b/llvm/docs/GettingStarted.rst --- a/llvm/docs/GettingStarted.rst +++ b/llvm/docs/GettingStarted.rst @@ -457,7 +457,7 @@ You'll generally want to make sure your branch has a single commit, corresponding to the review you wish to send, up-to-date with the upstream -``origin/master`` branch, and doesn't contain merges. Once you have that, you +``origin/main`` branch, and doesn't contain merges. Once you have that, you can start `a Phabricator review `_ (or use ``git show`` or ``git format-patch`` to output the diff, and attach it to an email message). @@ -501,7 +501,7 @@ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Once a patch is reviewed, you should rebase it, re-test locally, and commit the -changes to LLVM's master branch. This is done using `git push` if you have the +changes to LLVM's main branch. This is done using `git push` if you have the required access rights. See `committing a change `_ for Phabricator based commits or `obtaining commit access `_ @@ -515,13 +515,13 @@ # Go to the branch with your accepted commit. % git checkout branch-with-change # Rebase your change onto the latest commits on Github. - % git pull --rebase origin master + % git pull --rebase origin main # Rerun the appropriate tests if needed. % ninja check-$whatever # Check that the list of commits about to be pushed is correct. - % git log origin/master...HEAD --oneline + % git log origin/main...HEAD --oneline # Push to Github. - % git push origin HEAD:master + % git push origin HEAD:main LLVM currently has a linear-history policy, which means that merge commits are not allowed. The `llvm-project` repo on github is configured to reject pushes diff --git a/llvm/docs/GitBisecting.rst b/llvm/docs/GitBisecting.rst --- a/llvm/docs/GitBisecting.rst +++ b/llvm/docs/GitBisecting.rst @@ -23,7 +23,7 @@ .. code-block:: bash git bisect start - git bisect bad master + git bisect bad main git bisect good f00ba git will check out a revision in between. Try to reproduce your problem at @@ -33,8 +33,8 @@ ``git bisect skip`` and git will pick a nearby alternate commit. (To abort a bisect, run ``git bisect reset``, and if git complains about not -being able to reset, do the usual ``git checkout -f master; git reset --hard -origin/master`` dance and try again). +being able to reset, do the usual ``git checkout -f main; git reset --hard +origin/main`` dance and try again). ``git bisect run`` ================== diff --git a/llvm/docs/GlobalISel/IRTranslator.rst b/llvm/docs/GlobalISel/IRTranslator.rst --- a/llvm/docs/GlobalISel/IRTranslator.rst +++ b/llvm/docs/GlobalISel/IRTranslator.rst @@ -91,5 +91,5 @@ during :ref:`instructionselect`, while still avoiding redundant materializations for expensive non-foldable constants. However, this can lead to unnecessary spills and reloads in an -O0 pipeline, as these virtual registers can have long -live ranges. This can be mitigated by running a `localizer `_ +live ranges. This can be mitigated by running a `localizer `_ after the translator. diff --git a/llvm/docs/LibFuzzer.rst b/llvm/docs/LibFuzzer.rst --- a/llvm/docs/LibFuzzer.rst +++ b/llvm/docs/LibFuzzer.rst @@ -571,7 +571,7 @@ Currently, there is no simple way to run both fuzzing engines in parallel while sharing the same corpus dir. You may also use AFL on your target function ``LLVMFuzzerTestOneInput``: -see an example `here `__. +see an example `here `__. How good is my fuzzer? ---------------------- @@ -815,7 +815,7 @@ .. _AddressSanitizer: https://clang.llvm.org/docs/AddressSanitizer.html .. _LeakSanitizer: https://clang.llvm.org/docs/LeakSanitizer.html .. _Heartbleed: http://en.wikipedia.org/wiki/Heartbleed -.. _FuzzerInterface.h: https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/fuzzer/FuzzerInterface.h +.. _FuzzerInterface.h: https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/fuzzer/FuzzerInterface.h .. _3.7.0: https://llvm.org/releases/3.7.0/docs/LibFuzzer.html .. _building Clang from trunk: https://clang.llvm.org/get_started.html .. _MemorySanitizer: https://clang.llvm.org/docs/MemorySanitizer.html diff --git a/llvm/docs/TestingGuide.rst b/llvm/docs/TestingGuide.rst --- a/llvm/docs/TestingGuide.rst +++ b/llvm/docs/TestingGuide.rst @@ -73,7 +73,7 @@ regression tests, by creating a separate "Printer" pass to consume the analysis result and print it on the standard output in a textual format suitable for FileCheck. -See `llvm/test/Analysis/BranchProbabilityInfo/loop.ll `_ +See `llvm/test/Analysis/BranchProbabilityInfo/loop.ll `_ for an example of such test. ``test-suite`` diff --git a/llvm/docs/TypeMetadata.rst b/llvm/docs/TypeMetadata.rst --- a/llvm/docs/TypeMetadata.rst +++ b/llvm/docs/TypeMetadata.rst @@ -223,7 +223,7 @@ ret void } -.. _GlobalLayoutBuilder: https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Transforms/IPO/LowerTypeTests.h +.. _GlobalLayoutBuilder: https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Transforms/IPO/LowerTypeTests.h ``!vcall_visibility`` Metadata ==============================