Adjust documentation for git migration.

[jyknight]

Summary

This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/

to instead point to https://github.com/llvm/llvm-project.

This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.

I've attempted to *NOT* change any scripts here, only
documentation. The scripts will have to be addressed separately.

[jyknight]

Fix some warnings I added.

Restore TestSuiteMakefileGuide.rst, which apparently isn't 100%
obsolete. (But it is incorrect, and I'm not sure exactly how to fix
it, so I just left a FIXME).

[smeenai]

The amount of duplicated and out-of-date documentation makes me sad, but this is an awesome effort to clean that up.

lldb/packages/Python/lldbsuite/test/functionalities/command_source/TestCommandSource.py

4 ↗

(On Diff #183891)

Would you want to link to the corresponding GitHub commit?

lldb/packages/Python/lldbsuite/test/lang/objc/objc-optimized/TestObjcOptimized.py

4 ↗

(On Diff #183891)

Same here.

[mehdi_amini]

LGTM, but for one comment that requires a fix I believe (lld on Windows)

libcxx/docs/BuildingLibcxx.rst

47 ↗

(On Diff #183891)

So nice to see these steps going away :)

57 ↗

(On Diff #183891)

Wonder if it is worth mentioning somewhere how to sparse-checkout?

libcxxabi/www/index.html

86 ↗

(On Diff #183891)

Do you now if prefixing with CC is equivalent to -DCMAKE_C_COMPILER?

lld/docs/getting_started.rst

71 ↗

(On Diff #183891)

Missing -DLLVM_ENABLE_PROJECTS=lld here I believe

[labath]

I am not sure we should be recommending to people to place the build folder under the llvm-project checkout. Is that how people use the monorepo build nowadays? This is not an full out-of-source build, since the build folder is still a subfolder of the repo root (and without a .gitignore file containing the right build folder name, git will complain about untracked files in the repository)...

libcxxabi/www/index.html

86 ↗

(On Diff #183891)

It usually is, but it can differ once you start using cache and toolchain files. In any case, using -DCMAKE_C(XX)_COMPILER is the preferred way to do things in cmake.

[jyknight]

In D57330#1375096, @labath wrote:

I am not sure we should be recommending to people to place the build folder under the llvm-project checkout. Is that how people use the monorepo build nowadays? This is not an full out-of-source build, since the build folder is still a subfolder of the repo root (and without a .gitignore file containing the right build folder name, git will complain about untracked files in the repository)...

Well, it's certainly how I do it. I find it the least confusing, because then I don't get mixed up as to which source tree a given build directory belongs to (or directories, as I may also have build-release, build-debug, etc).

libcxx/docs/BuildingLibcxx.rst

57 ↗

(On Diff #183891)

Yes, I think it likely is worth mentioning that somewhere in the future -- but I'd rather not recommend it yet. There's two things that will impact that:

1. We'll need to decide where we plan to keep shared infrastructure (e.g. cmake macros etc) used by multiple subprojects within the repository.
2. It seems as though git is actually gaining new support for this kind of thing now, might be worth letting that mature a little bit.

libcxxabi/www/index.html

86 ↗

(On Diff #183891)

Changed to specify the cmake arguments.

lld/docs/getting_started.rst

71 ↗

(On Diff #183891)

Yep fixed.

lldb/packages/Python/lldbsuite/test/functionalities/command_source/TestCommandSource.py

4 ↗

(On Diff #183891)

After viewing said commit, I felt it wasn't actually useful to visit to understand this file, which is why I removed the link.

lldb/packages/Python/lldbsuite/test/lang/objc/objc-optimized/TestObjcOptimized.py

4 ↗

(On Diff #183891)

Felt the same in this case.

[mehdi_amini]

In D57330#1375096, @labath wrote:

This is not an full out-of-source build, since the build folder is still a subfolder of the repo root

My definition of what qualify an "out-of-source" build is that the build process won't touch anything outside of the build directory: i.e. the build directory itself is hermetic, self-contained, and can be destroyed without impacting anything else.
(I agree with you that polluting git status is annoying, and personally I usually have my build directories in parallel with the repo).

[smeenai]

In D57330#1375913, @mehdi_amini wrote:

In D57330#1375096, @labath wrote:

This is not an full out-of-source build, since the build folder is still a subfolder of the repo root

My definition of what qualify an "out-of-source" build is that the build process won't touch anything outside of the build directory: i.e. the build directory itself is hermetic, self-contained, and can be destroyed without impacting anything else.
(I agree with you that polluting git status is annoying, and personally I usually have my build directories in parallel with the repo).

You can avoid the git status pollution by adding the build directory to .git/info/exclude.

[mehdi_amini]

You can avoid the git status pollution by adding the build directory to .git/info/exclude.

Good to know! Should we include this in the doc?

[smeenai]

In D57330#1376069, @mehdi_amini wrote:

You can avoid the git status pollution by adding the build directory to .git/info/exclude.

Good to know! Should we include this in the doc?

I can put that change up fore review. It probably makes most sense to add it to www/get_started.html? There's lots of different places which document building, but that seems like the canonical one.

.gitignore

 #==============================================================================#
 # This file specifies intentionally untracked files that git should ignore.
 # See: http://www.kernel.org/pub/software/scm/git/docs/gitignore.html
-#
-# This file is intentionally different from the output of `git svn show-ignore`,
-# as most of those are useless.
 #==============================================================================#
 
 #==============================================================================#
 # File extensions to be ignored anywhere in the tree.
 #==============================================================================#
 # Temp files created by most text editors.
 *~
 # Merge files created by git.

docs/ClangPlugins.rst

.. code-block:: c++
   static PragmaHandlerRegistry::Add<ExamplePragmaHandler> Y("example_pragma","example pragma description");
 
 Putting it all together
 =======================
 
 Let's look at an example plugin that prints top-level function names.  This
 example is checked into the clang repository; please take a look at
 the `latest version of PrintFunctionNames.cpp
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/examples/PrintFunctionNames/PrintFunctionNames.cpp?view=markup>`_.
+<https://github.com/llvm/llvm-project/blob/master/clang/examples/PrintFunctionNames/PrintFunctionNames.cpp>`_.
 
 Running the plugin
 ==================
 
 
 Using the cc1 command line
 --------------------------
 
.. code-block:: console
   $ clang++ -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS \
             -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE \
             -I$BD/tools/clang/include -Itools/clang/include -I$BD/include -Iinclude \
             tools/clang/tools/clang-check/ClangCheck.cpp -fsyntax-only \
             -Xclang -load -Xclang $BD/lib/PrintFunctionNames.so -Xclang \
             -plugin -Xclang print-fns
 
 Also see the print-function-name plugin example's
-`README <https://llvm.org/viewvc/llvm-project/cfe/trunk/examples/PrintFunctionNames/README.txt?view=markup>`_
+`README <https://github.com/llvm/llvm-project/blob/master/clang/examples/PrintFunctionNames/README.txt>`_
 
 
 Using the clang command line
 ----------------------------
 
 Using `-fplugin=plugin` on the clang command line passes the plugin
 through as an argument to `-load` on the cc1 command line. If the plugin
 class implements the ``getActionType`` method then the plugin is run

docs/ClangTools.rst

 ========
 Overview
 ========
 
 Clang Tools are standalone command line (and potentially GUI) tools
 designed for use by C++ developers who are already using and enjoying
 Clang as their compiler. These tools provide developer-oriented
 functionality such as fast syntax checking, automatic formatting,
 refactoring, etc.
 
 Only a couple of the most basic and fundamental tools are kept in the
-primary Clang Subversion project. The rest of the tools are kept in a
-side-project so that developers who don't want or need to build them
-don't. If you want to get access to the extra Clang Tools repository,
-simply check it out into the tools tree of your Clang checkout and
-follow the usual process for building and working with a combined
-LLVM/Clang checkout:
-
--  With Subversion:
-
-   -  ``cd llvm/tools/clang/tools``
-   -  ``svn co https://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra``
-
--  Or with Git:
-
-   -  ``cd llvm/tools/clang/tools``
-   -  ``git clone https://llvm.org/git/clang-tools-extra.git extra``
+primary Clang tree. The rest of the tools are kept in a separate
+directory tree, ``clang-tools-extra
+<https://github.com/llvm/llvm-project/tree/master/clang-tools-extra>``_.
 
 This document describes a high-level overview of the organization of
 Clang Tools within the project as well as giving an introduction to some
 of the more important tools. However, it should be noted that this
 document is currently focused on Clang and Clang Tool developers, not on
 end users of these tools.
 
 Clang Tools Organization

docs/ControlFlowIntegrityDesign.rst

 The compiler lays out classes of disjoint hierarchies in separate regions
 of the object file. At worst, bit vectors in disjoint hierarchies only
 need to cover their disjoint hierarchy. But the closer that classes in
 sub-hierarchies are laid out to each other, the smaller the bit vectors for
 those sub-hierarchies need to be (see "Stripping Leading/Trailing Zeros in Bit
 Vectors" above). The `GlobalLayoutBuilder`_ class is responsible for laying
 out the globals efficiently to minimize the sizes of the underlying bitsets.
 
-.. _GlobalLayoutBuilder: https://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Transforms/IPO/LowerTypeTests.h?view=markup
+.. _GlobalLayoutBuilder: https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Transforms/IPO/LowerTypeTests.h
 
 Alignment
 ~~~~~~~~~
 
 If all gaps between address points in a particular bit vector are multiples
 of powers of 2, the compiler can compress the bit vector by strengthening
 the alignment requirements of the virtual table pointer. For example, given
 this class hierarchy:

 Split virtual table groups into separate virtual tables
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The Itanium C++ ABI glues multiple individual virtual tables for a class into a combined virtual table (virtual table group). 
 The interleaving scheme, however, can only work with individual virtual tables so it must split the combined virtual tables first.
 In comparison, the old scheme does not require the splitting but it is more efficient when the combined virtual tables have been split.
 The `GlobalSplit`_ pass is responsible for splitting combined virtual tables into individual ones. 
 
-.. _GlobalSplit: https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/IPO/GlobalSplit.cpp?view=markup
+.. _GlobalSplit: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/IPO/GlobalSplit.cpp
 
 Order virtual tables by a pre-order traversal of the class hierarchy 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This step is common to both the old scheme described above and the interleaving scheme. 
 For the interleaving scheme, since the combined virtual tables have been split in the previous step, 
 this step ensures that for any class all the compatible virtual tables will appear consecutively. 
 For the old scheme, the same property may not hold since it may work on combined virtual tables. 

docs/InternalsManual.rst

 derived from ``clang::Attr``, information for the parser to use, automated
 semantic checking for some attributes, etc.
 
 
 ``include/clang/Basic/Attr.td``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The first step to adding a new attribute to Clang is to add its definition to
 `include/clang/Basic/Attr.td
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?view=markup>`_.
+<https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Basic/Attr.td>`_.
 This tablegen definition must derive from the ``Attr`` (tablegen, not
 semantic) type, or one of its derivatives. Most attributes will derive from the
 ``InheritableAttr`` type, which specifies that the attribute can be inherited by
 later redeclarations of the ``Decl`` it is associated with.
 ``InheritableParamAttr`` is similar to ``InheritableAttr``, except that the
 attribute is written on a parameter instead of a declaration. If the attribute
 is intended to apply to a type instead of a declaration, such an attribute
 should derive from ``TypeAttr``, and will generally not be given an AST

 automatically. Whether the diagnostic is a warning or an error depends on how
 the attribute's ``SubjectList`` is defined, but the default behavior is to warn.
 The diagnostics displayed to the user are automatically determined based on the
 subjects in the list, but a custom diagnostic parameter can also be specified in
 the ``SubjectList``. The diagnostics generated for subject list violations are
 either ``diag::warn_attribute_wrong_decl_type`` or
 ``diag::err_attribute_wrong_decl_type``, and the parameter enumeration is found
 in `include/clang/Sema/ParsedAttr.h
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/ParsedAttr.h?view=markup>`_
+<https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Sema/ParsedAttr.h>`_
 If a previously unused Decl node is added to the ``SubjectList``, the logic used
 to automatically determine the diagnostic parameter in `utils/TableGen/ClangAttrEmitter.cpp
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?view=markup>`_
+<https://github.com/llvm/llvm-project/blob/master/clang/utils/TableGen/ClangAttrEmitter.cpp>`_
 may need to be updated.
 
 By default, all subjects in the SubjectList must either be a Decl node defined
 in ``DeclNodes.td``, or a statement node defined in ``StmtNodes.td``. However,
 more complex subjects can be created by creating a ``SubsetSubject`` object.
 Each such object has a base subject which it appertains to (which must be a
 Decl or Stmt node, and not a SubsetSubject node), and some custom code which is
 called when determining whether an attribute appertains to the subject. For
 instance, a ``NonBitField`` SubsetSubject appertains to a ``FieldDecl``, and
 tests whether the given FieldDecl is a bit field. When a SubsetSubject is
 specified in a SubjectList, a custom diagnostic parameter must also be provided.
 
 Diagnostic checking for attribute subject lists is automated except when
 ``HasCustomParsing`` is set to ``1``.
 
 Documentation
 ~~~~~~~~~~~~~
 All attributes must have some form of documentation associated with them.
 Documentation is table generated on the public web server by a server-side
 process that runs daily. Generally, the documentation for an attribute is a
 stand-alone definition in `include/clang/Basic/AttrDocs.td 
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttdDocs.td?view=markup>`_
+<https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Basic/AttrDocs.td>`_
 that is named after the attribute being documented.
 
 If the attribute is not for public consumption, or is an implicitly-created
 attribute that has no visible spelling, the documentation list can specify the
 ``Undocumented`` object. Otherwise, the attribute should have its documentation
 added to AttrDocs.td.
 
 Documentation derives from the ``Documentation`` tablegen type. All derived

 ``__attribute__((myattribute("Hello", 3)))`` will be a valid use; it requires
 two arguments while parsing, and the Attr subclass' constructor for the
 semantic attribute will require a string and integer argument.
 
 All arguments have a name and a flag that specifies whether the argument is
 optional. The associated C++ type of the argument is determined by the argument
 definition type. If the existing argument types are insufficient, new types can
 be created, but it requires modifying `utils/TableGen/ClangAttrEmitter.cpp
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?view=markup>`_
+<https://github.com/llvm/llvm-project/blob/master/clang/utils/TableGen/ClangAttrEmitter.cpp>`_
 to properly support the type.
 
 Other Properties
 ~~~~~~~~~~~~~~~~
 The ``Attr`` definition has other members which control the behavior of the
 attribute. Many of them are special-purpose and beyond the scope of this
 document, however a few deserve mention.
 
 If the parsed form of the attribute is more complex, or differs from the
 semantic form, the ``HasCustomParsing`` bit can be set to ``1`` for the class,
 and the parsing code in `Parser::ParseGNUAttributeArgs()
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?view=markup>`_
+<https://github.com/llvm/llvm-project/blob/master/clang/lib/Parse/ParseDecl.cpp>`_
 can be updated for the special case. Note that this only applies to arguments
 with a GNU spelling -- attributes with a __declspec spelling currently ignore
 this flag and are handled by ``Parser::ParseMicrosoftDeclSpec``.
 
 Note that setting this member to 1 will opt out of common attribute semantic
 handling, requiring extra implementation efforts to ensure the attribute
 appertains to the appropriate subject, etc.
 

 
 If additional functionality is desired for the semantic form of the attribute,
 the ``AdditionalMembers`` field specifies code to be copied verbatim into the
 semantic attribute class object, with ``public`` access.
 
 Boilerplate
 ^^^^^^^^^^^
 All semantic processing of declaration attributes happens in `lib/Sema/SemaDeclAttr.cpp
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?view=markup>`_,
+<https://github.com/llvm/llvm-project/blob/master/clang/lib/Sema/SemaDeclAttr.cpp>`_,
 and generally starts in the ``ProcessDeclAttribute()`` function. If the
 attribute is a "simple" attribute -- meaning that it requires no custom semantic
 processing aside from what is automatically  provided, add a call to
 ``handleSimpleAttribute<YourAttr>(S, D, Attr);`` to the switch statement.
 Otherwise, write a new ``handleYourAttr()`` function, and add that to the switch
 statement. Please do not implement handling logic directly in the ``case`` for
 the attribute.
 
 Unless otherwise specified by the attribute definition, common semantic checking
 of the parsed attribute is handled automatically. This includes diagnosing
 parsed attributes that do not appertain to the given ``Decl``, ensuring the
 correct minimum number of arguments are passed, etc.
 
 If the attribute adds additional warnings, define a ``DiagGroup`` in
 `include/clang/Basic/DiagnosticGroups.td
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?view=markup>`_
+<https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Basic/DiagnosticGroups.td>`_
 named after the attribute's ``Spelling`` with "_"s replaced by "-"s. If there
 is only a single diagnostic, it is permissible to use ``InGroup<DiagGroup<"your-attribute">>``
 directly in `DiagnosticSemaKinds.td
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?view=markup>`_
+<https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Basic/DiagnosticSemaKinds.td>`_
 
 All semantic diagnostics generated for your attribute, including automatically-
 generated ones (such as subjects and argument counts), should have a
 corresponding test case.
 
 Semantic handling
 ^^^^^^^^^^^^^^^^^
 Most attributes are implemented to have some effect on the compiler. For

docs/LibASTMatchersTutorial.rst

 abstract syntax tree (AST). To this end, the reader is incouraged to
 skim the :doc:`Introduction to the Clang
 AST <IntroductionToTheClangAST>`
 
 Step 0: Obtaining Clang
 =======================
 
 As Clang is part of the LLVM project, you'll need to download LLVM's
-source code first. Both Clang and LLVM are maintained as Subversion
-repositories, but we'll be accessing them through the git mirror. For
-further information, see the `getting started
-guide <https://llvm.org/docs/GettingStarted.html>`_.
+source code first. Both Clang and LLVM are in the same git repository,
+under different directories. For further information, see the `getting
+started guide <https://llvm.org/docs/GettingStarted.html>`_.
 
 .. code-block:: console
 
-      mkdir ~/clang-llvm && cd ~/clang-llvm
-      git clone https://llvm.org/git/llvm.git
-      cd llvm/tools
-      git clone https://llvm.org/git/clang.git
-      cd clang/tools
-      git clone https://llvm.org/git/clang-tools-extra.git extra
-
-Next you need to obtain the CMake build system and Ninja build tool. You
-may already have CMake installed, but current binary versions of CMake
-aren't built with Ninja support.
+      cd ~/clang-llvm
+      git clone https://github.com/llvm/llvm-project.git
+
+Next you need to obtain the CMake build system and Ninja build tool.
 
 .. code-block:: console
 
       cd ~/clang-llvm
       git clone https://github.com/martine/ninja.git
       cd ninja
       git checkout release
       ./bootstrap.py
       sudo cp ninja /usr/bin/
 
       cd ~/clang-llvm
       git clone git://cmake.org/stage/cmake.git
       cd cmake
       git checkout next
       ./bootstrap
       make
       sudo make install
 
 Okay. Now we'll build Clang!
 
 .. code-block:: console
 
       cd ~/clang-llvm
       mkdir build && cd build
-      cmake -G Ninja ../llvm -DLLVM_BUILD_TESTS=ON  # Enable tests; default is off.
+      cmake -G Ninja ../llvm -DLLVM_ENABLE_PROJECTS=clang -DLLVM_BUILD_TESTS=ON  # Enable tests; default is off.
       ninja
       ninja check       # Test LLVM only.
       ninja clang-test  # Test Clang only.
       ninja install
 
 And we're live.
 
-All of the tests should pass, though there is a (very) small chance that
-you can catch LLVM and Clang out of sync. Running ``'git svn rebase'``
-in both the llvm and clang directories should fix any problems.
+All of the tests should pass.
 
 Finally, we want to set Clang as its own compiler.
 
 .. code-block:: console
 
       cd ~/clang-llvm/build
       ccmake ../llvm
 

docs/LibTooling.rst

 the binary directory of a clang install next to the clang binary.
 
 Tips: if your tool fails to find ``stddef.h`` or similar headers, call the tool
 with ``-v`` and look at the search paths it looks through.
 
 Linking
 ^^^^^^^
 
-For a list of libraries to link, look at one of the tools' Makefiles (for
-example `clang-check/Makefile
-<https://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-check/Makefile?view=markup>`_).
+For a list of libraries to link, look at one of the tools' CMake files (for
+example `clang-check/CMakeList.txt
+<https://github.com/llvm/llvm-project/blob/master/clang/tools/clang-check/CMakeLists.txt>`_).

docs/Toolchain.rst

 the language-neutral stack unwinding portion of the Itanium C++ ABI
 (`Level I <https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#base-abi>`_).
 It is a dependency of the C++ ABI library, and sometimes is a dependency
 of other runtimes.
 
 libunwind (LLVM)
 ^^^^^^^^^^^^^^^^
 
-LLVM's unwinder library can be obtained from subversion:
-
-.. code-block:: console
-
-  llvm-src$ svn co https://llvm.org/svn/llvm-project/libunwind/trunk projects/libunwind
-
-When checked out into projects/libunwind within an LLVM checkout,
-it should be automatically picked up by the LLVM build system.
+LLVM's unwinder library is part of the llvm-project git repository. To
+build it, pass ``-DLLVM_ENABLE_PROJECTS=libunwind`` to the cmake invocation.
 
 If using libc++abi, you may need to configure it to use libunwind
 rather than libgcc_s by passing ``-DLIBCXXABI_USE_LLVM_UNWINDER=YES``
 to ``cmake``. If libc++abi is configured to use some version of
 libunwind, that library will be implicitly linked into binaries that
 link to libc++abi.
 
 libgcc_s (GNU)

lib/CodeGen/CGOpenMPRuntime.cpp

~InlinedOpenMPRegionRAII() {
     std::swap(CGF.LambdaCaptureFields, LambdaCaptureFields);
     CGF.LambdaThisCaptureField = LambdaThisCaptureField;
     CGF.BlockInfo = BlockInfo;
   }
 };
 
 /// Values for bit flags used in the ident_t to describe the fields.
 /// All enumeric elements are named and described in accordance with the code
-/// from http://llvm.org/svn/llvm-project/openmp/trunk/runtime/src/kmp.h
+/// from https://github.com/llvm/llvm-project/blob/master/openmp/runtime/src/kmp.h
 enum OpenMPLocationFlags : unsigned {
   /// Use trampoline for internal microtask.
   OMP_IDENT_IMD = 0x01,
   /// Use c-style ident structure.
   OMP_IDENT_KMPC = 0x02,
   /// Atomic reduction option for kmpc_reduce.
   OMP_ATOMIC_REDUCE = 0x10,
   /// Explicit 'barrier' directive.
enum OpenMPLocationFlags : unsigned {
   OMP_IDENT_WORK_SECTIONS = 0x400,
   /// Call of __kmp_for_static_init for distribute.
   OMP_IDENT_WORK_DISTRIBUTE = 0x800,
   LLVM_MARK_AS_BITMASK_ENUM(/*LargestValue=*/OMP_IDENT_WORK_DISTRIBUTE)
 };
 
 /// Describes ident structure that describes a source location.
 /// All descriptions are taken from
-/// http://llvm.org/svn/llvm-project/openmp/trunk/runtime/src/kmp.h
+/// https://github.com/llvm/llvm-project/blob/master/openmp/runtime/src/kmp.h
 /// Original structure:
 /// typedef struct ident {
 ///    kmp_int32 reserved_1;   /**<  might be used in Fortran;
 ///                                  see above  */
 ///    kmp_int32 flags;        /**<  also f.flags; KMP_IDENT_xxx flags;
 ///                                  KMP_IDENT_KMPC identifies this union
 ///                                  member  */
 ///    kmp_int32 reserved_2;   /**<  not really used in Fortran any more;
Address CGOpenMPRuntime::getOrCreateDefaultLocation(unsigned Flags) {
   unsigned Reserved2Flags = getDefaultLocationReserved2Flags();
   FlagsTy FlagsKey(Flags, Reserved2Flags);
   llvm::Value *Entry = OpenMPDefaultLocMap.lookup(FlagsKey);
   if (!Entry) {
     if (!DefaultOpenMPPSource) {
       // Initialize default location for psource field of ident_t structure of
       // all ident_t objects. Format is ";file;function;line;column;;".
       // Taken from
-      // http://llvm.org/svn/llvm-project/openmp/trunk/runtime/src/kmp_str.c
+      // https://github.com/llvm/llvm-project/blob/master/openmp/runtime/src/kmp_str.cpp
       DefaultOpenMPPSource =
           CGM.GetAddrOfConstantCString(";unknown;unknown;0;0;;").getPointer();
       DefaultOpenMPPSource =
           llvm::ConstantExpr::getBitCast(DefaultOpenMPPSource, CGM.Int8PtrTy);
     }
 
     llvm::Constant *Data[] = {
         llvm::ConstantInt::getNullValue(CGM.Int32Ty),
llvm::Value *TaskEntry = emitProxyTaskFunction(
       CGM, Loc, D.getDirectiveKind(), KmpInt32Ty, KmpTaskTWithPrivatesPtrQTy,
       KmpTaskTWithPrivatesQTy, KmpTaskTQTy, SharedsPtrTy, TaskFunction,
       TaskPrivatesMap);
 
   // Build call kmp_task_t * __kmpc_omp_task_alloc(ident_t *, kmp_int32 gtid,
   // kmp_int32 flags, size_t sizeof_kmp_task_t, size_t sizeof_shareds,
   // kmp_routine_entry_t *task_entry);
   // Task flags. Format is taken from
-  // http://llvm.org/svn/llvm-project/openmp/trunk/runtime/src/kmp.h,
+  // https://github.com/llvm/llvm-project/blob/master/openmp/runtime/src/kmp.h,
   // description of kmp_tasking_flags struct.
   enum {
     TiedFlag = 0x1,
     FinalFlag = 0x2,
     DestructorsFlag = 0x8,
     PriorityFlag = 0x20
   };
   unsigned Flags = Data.Tied ? TiedFlag : 0;

 }
 
 Address
 CGOpenMPSIMDRuntime::getParameterAddress(CodeGenFunction &CGF,
                                          const VarDecl *NativeParam,
                                          const VarDecl *TargetParam) const {
   llvm_unreachable("Not supported in SIMD-only mode");
 }
-

www/analyzer/checker_dev_manual.html

 
 Here are some additional resources that are useful when working on the Clang
 Static Analyzer:
 
 <ul>
 <li><a href="http://lcs.ios.ac.cn/~xuzb/canalyze/memmodel.pdf">Xu, Zhongxing &
 Kremenek, Ted & Zhang, Jian. (2010). A Memory Model for Static Analysis of C
 Programs.</a></li>
-<li><a href="https://github.com/llvm-mirror/clang/blob/master/lib/StaticAnalyzer/README.txt">
+<li><a href="https://github.com/llvm/llvm-project/blob/master/clang/lib/StaticAnalyzer/README.txt">
 The Clang Static Analyzer README</a></li>
-<li><a href="https://github.com/llvm-mirror/clang/blob/master/docs/analyzer/RegionStore.txt">
+<li><a href="https://github.com/llvm/llvm-project/blob/master/clang/docs/analyzer/RegionStore.txt">
 Documentation for how the Store works</a></li>
-<li><a href="https://github.com/llvm-mirror/clang/blob/master/docs/analyzer/IPA.txt">
+<li><a href="https://github.com/llvm/llvm-project/blob/master/clang/docs/analyzer/IPA.txt">
 Documentation about inlining</a></li>
 <li> The "Building a Checker in 24 hours" presentation given at the <a
 href="http://llvm.org/devmtg/2012-11">November 2012 LLVM Developer's
 meeting</a>. Describes the construction of SimpleStreamChecker. <a
 href="http://llvm.org/devmtg/2012-11/Zaks-Rose-Checker24Hours.pdf">Slides</a>
 and <a
 href="https://youtu.be/kdxlsP5QVPw">video</a>
 are available.</li>

www/get_started.html

 
 <p>Clang is released as part of regular LLVM releases. You can download the release versions from <a href="https://llvm.org/releases/">https://llvm.org/releases/</a>.</p>
 <p>Clang is also provided in all major BSD or GNU/Linux distributions as part of their respective packaging systems. From Xcode 4.2, Clang is the default compiler for Mac OS X.</p>
 
 <h2 id="build">Building Clang and Working with the Code</h2>
 
 <h3 id="buildNix">On Unix-like Systems</h3>
 
-<p>Note: as an experimental setup, you can use a <b>single checkout</b> with all the projects, and an <b>easy CMake invocation</b>, see the LLVM Doc "<a href="https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo">For developers to work with a git monorepo</a>"</p>
-
 <p>If you would like to check out and build Clang, the current procedure is as
 follows:</p>
 
 <ol>
   <li>Get the required tools.
   <ul>
     <li>See
       <a href="https://llvm.org/docs/GettingStarted.html#requirements">
       Getting Started with the LLVM System - Requirements</a>.</li>
     <li>Note also that Python is needed for running the test suite.
       Get it at: <a href="http://www.python.org/download">
       http://www.python.org/download</a></li>
     <li>Standard build process uses CMake. Get it at:
       <a href="http://www.cmake.org/download">
       http://www.cmake.org/download</a></li>
   </ul>
 
-  <li>Check out LLVM:
+  <li>Check out the LLVM project:
   <ul>
     <li>Change directory to where you want the llvm directory placed.</li>
-    <li><tt>svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm</tt></li>
-  </ul>
-  </li>
-  <li>Check out Clang:
-  <ul>
-    <li><tt>cd llvm/tools</tt></li>
-    <li><tt>svn co http://llvm.org/svn/llvm-project/cfe/trunk clang</tt></li>
-    <li><tt>cd ../..</tt></li>
-  </ul>
-  </li>
-  <li>Check out extra Clang tools: (optional)
-  <ul>
-    <li><tt>cd llvm/tools/clang/tools</tt></li>
-    <li><tt>svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk
-        extra</tt></li>
-    <li><tt>cd ../../../..</tt></li>
-  </ul>
-  </li>
-  <li>Check out Compiler-RT (optional):
-  <ul>
-    <li><tt>cd llvm/projects</tt></li>
-    <li><tt>svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk
-        compiler-rt</tt></li>
-    <li><tt>cd ../..</tt></li>
-  </ul>
-  </li>
-  <li>Check out libcxx: (only required to build and run Compiler-RT tests on OS X, optional otherwise)
-  <ul>
-    <li><tt>cd llvm/projects</tt></li>
-    <li><tt>svn co http://llvm.org/svn/llvm-project/libcxx/trunk
-        libcxx</tt></li>
-    <li><tt>cd ../..</tt></li>
+    <li><tt>git clone https://github.com/llvm/llvm-project.git</tt></li>
   </ul>
   </li>
   <li>Build LLVM and Clang:
   <ul>
+    <li><tt>cd llvm-project</tt></li>
     <li><tt>mkdir build</tt> (in-tree build is not supported)</li>
     <li><tt>cd build</tt></li>
-    <li><tt>cmake -G "Unix Makefiles" ../llvm</tt></li>
+    <li><tt>cmake -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles" ../llvm</tt></li>
     <li><tt>make</tt></li>
     <li>This builds both LLVM and Clang for debug mode.</li>
     <li>Note: For subsequent Clang development, you can just run
         <tt>make clang</tt>.</li>
     <li>CMake allows you to generate project files for several IDEs: Xcode,
         Eclipse CDT4, CodeBlocks, Qt-Creator (use the CodeBlocks generator),
         KDevelop3. For more details see
         <a href="https://llvm.org/docs/CMake.html">Building LLVM with CMake</a>
<ol>
   </li>
   <li>Run the testsuite:
   <ul>
     <li><tt>make check-clang</tt></li>
   </ul>
   </li>
 </ol>
 
-<h3>Simultaneously Building Clang and LLVM:</h3>
-
-<p>Once you have checked out Clang into the llvm source tree it will build along
-with the rest of <tt>llvm</tt>. To build all of LLVM and Clang together all at
-once simply run <tt>make</tt> from the root LLVM directory.</p>
-
-<p>If you encounter problems while building Clang, make sure that your LLVM
-checkout is at the same revision as your Clang checkout. LLVM's interfaces
-change over time, and mismatched revisions are not expected to work
-together. We recommend writing a script to automatically run <tt>svn up</tt> in
-each repository to keep them synchronized. Alternatively, you may consider using
-the unofficial
-<a href="https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo">git monorepo</a>
-which automatically keeps everything in sync at the same revision and lets you
-commit changes atomically across multiple LLVM subprojects.</p>
-
 <h3 id="buildWindows">Using Visual Studio</h3>
 
 <p>The following details setting up for and building Clang on Windows using
 Visual Studio:</p>
 
 <ol>
   <li>Get the required tools:
   <ul>
-    <li><b>Subversion</b>.  Source code control program.  Get it from:
-        <a href="https://subversion.apache.org/packages.html">
-        https://subversion.apache.org/packages.html</a></li>
+    <li><b>Git</b>.  Source code control program.  Get it from:
+        <a href="https://git-scm.com/download">
+        https://git-scm.com/download</a></li>
     <li><b>CMake</b>.  This is used for generating Visual Studio solution and
         project files.  Get it from:
         <a href="https://cmake.org/download/">
         https://cmake.org/download/</a></li>
     <li><b>Visual Studio 2015 or later</b></li>
     <li><b>Python</b>.  It is used to run the clang test suite. Get it from:
         <a href="https://www.python.org/download/">
         https://www.python.org/download/</a></li>
     <li><b>GnuWin32 tools</b>
         The Clang and LLVM test suite use various GNU core utilities, such as
         <tt>grep</tt>, <tt>sed</tt>, and <tt>find</tt>. The gnuwin32 packages
         are the oldest and most well-tested way to get these tools. However, the
         MSys utilities provided by git for Windows have been known to work.
         Cygwin has worked in the past, but is not well tested.
         If you don't already have the core utilies from some other source, get
         gnuwin32 from <a href="http://getgnuwin32.sourceforge.net/">
         http://getgnuwin32.sourceforge.net/</a>.</li>
   </ul>
   </li>
 
-  <li>Check out LLVM:
+  <li>Check out LLVM and Clang:
   <ul>
-    <li><tt>svn co https://llvm.org/svn/llvm-project/llvm/trunk llvm</tt></li>
-  </ul>
-  </li>
-  <li>Check out Clang:
-  <ul>
-     <li><tt>cd llvm\tools</tt>
-     <li><tt>svn co https://llvm.org/svn/llvm-project/cfe/trunk clang</tt></li>
+    <li><tt>git clone https://github.com/llvm/llvm-project.git</tt></li>
   </ul>
-  <p><em>Note</em>:  Some Clang tests are sensitive to the line endings.  Ensure
-     that checking out the files does not convert LF line endings to CR+LF.
-     If you use git-svn, make sure your <tt>core.autocrlf</tt> setting is false.</p>
+  <p><em>Note</em>: Some Clang tests are sensitive to the line endings.  Ensure
+     that checking out the files does not convert LF line endings to CR+LF.  If
+     you're using git on Windows, make sure your <tt>core.autocrlf</tt> setting
+     is false.</p>
   </li>
   <li>Run CMake to generate the Visual Studio solution and project files:
   <ul>
     <li><tt>cd ..\..</tt>  (back to where you started)</li>
     <li><tt>mkdir build</tt> (for building without polluting the source dir)</li>
     <li><tt>cd build</tt></li>
     <li>
       If you are using Visual Studio 2017:
-      <tt>cmake -G "Visual Studio 15 2017" -A x64 -Thost=x64 ..\llvm</tt><br/>
+      <tt>cmake -DLLVM_ENABLE_PROJECTS=clang -G "Visual Studio 15 2017" -A x64 -Thost=x64 ..\llvm</tt><br/>
       <tt>-Thost=x64</tt> is required, since the 32-bit linker will run out of memory.
     </li>
     <li>To generate x86 binaries instead of x64, pass <tt>-A Win32</tt>.</li>
     <li>See the <a href="https://www.llvm.org/docs/CMake.html">LLVM CMake guide</a> for
         more information on other configuration options for CMake.</li>
     <li>The above, if successful, will have created an LLVM.sln file in the
        <tt>build</tt> directory.
   </ul>
   </li>
   <li>Build Clang:
   <ul>
     <li>Open LLVM.sln in Visual Studio.</li>
     <li>Build the "clang" project for just the compiler driver and front end, or
       the "ALL_BUILD" project to build everything, including tools.</li>
   </ul>
   </li>
   <li>Try it out (assuming you added llvm/debug/bin to your path).  (See the
     running examples from above.)</li>
   <li>See <a href="hacking.html#testingWindows">
      Hacking on clang - Testing using Visual Studio on Windows</a> for information
      on running regression tests on Windows.</li>
 </ol>
 
-<p>Note that once you have checked out both llvm and clang, to synchronize
-to the latest code base, use the <tt>svn update</tt> command in both the
-llvm and llvm\tools\clang directories, as they are separate repositories.</p>
-
 <h3 id="buildWindowsNinja">Using Ninja alongside Visual Studio</h3>
 
 <p>We recommend that developers who want the fastest incremental builds use the
 <a href="https://ninja-build.org/">Ninja build system</a>. You can use the
 generated Visual Studio project files to edit Clang source code and generate a
 second build directory next to it for running the tests with these steps:</p>
 
 <ol>

www/hacking.html

<ul>
       <li>The <a href="docs/InternalsManual.html#QualType"><tt>QualType</tt></a>
       structure is used pervasively. This is a simple value class for
       wrapping types with qualifiers; you can use
       the <tt>isConstQualified()</tt>, for example, to get one of the
       qualifiers, and the <tt>getTypePtr()</tt> method to get the
       wrapped <tt>Type*</tt> which you can then dump.</li>
       <li>For <a href="http://lldb.llvm.org"> <tt>LLDB</tt></a> users there are
       data formatters for clang data structures in
-      <a href="http://llvm.org/svn/llvm-project/cfe/trunk/utils/ClangDataFormat.py">
-      <tt>utils/ClangDataFormat.py</tt></a>.</li>
+      <a href="https://github.com/llvm/llvm-project/blob/master/clang/utils/ClangDataFormat.py">
+      <tt>clang/utils/ClangDataFormat.py</tt></a>.</li>
     </ul>
 
   <!--=====================================================================-->
   <h3 id="debuggingVisualStudio">Debugging using Visual Studio</h3>
   <!--=====================================================================-->
 
-  <p>The files 
-    <a href="http://llvm.org/svn/llvm-project/llvm/trunk/utils/LLVMVisualizers/llvm.natvis">
-      <tt>utils/LLVMVisualizers/llvm.natvis</tt></a> and 
-    <a href="http://llvm.org/svn/llvm-project/cfe/trunk/utils/ClangVisualizers/clang.natvis">
-      <tt>utils/ClangVisualizers/clang.natvis</tt></a> provide debugger visualizers 
+  <p>The files
+    <a href="https://github.com/llvm/llvm-project/blob/master/llvm/utils/LLVMVisualizers/llvm.natvis">
+      <tt>llvm/utils/LLVMVisualizers/llvm.natvis</tt></a> and
+    <a href="https://github.com/llvm/llvm-project/blob/master/clang/utils/ClangVisualizers/clang.natvis">
+      <tt>clang/utils/ClangVisualizers/clang.natvis</tt></a> provide debugger visualizers
       that make debugging of more complex data types much easier.</p>
-  <p>For Visual Studio 2013 only, put the files into 
-    <tt>%USERPROFILE%\Documents\Visual Studio 2013\Visualizers</tt> or 
+  <p>For Visual Studio 2013 only, put the files into
+    <tt>%USERPROFILE%\Documents\Visual Studio 2013\Visualizers</tt> or
     create a symbolic link so they update automatically.</p>
   <p>For later versions of Visual Studio, no installation is required.
     Note also that later versions of Visual Studio also display better visualizations.</p>
 
   <!--=====================================================================-->
   <h2 id="testing">Testing</h2>
   <!--=====================================================================-->
 

www/menu.html.incl

<div class="submenu">
     <a href="http://lists.llvm.org/mailman/listinfo/cfe-commits">cfe-commits List</a>
     <a href="https://bugs.llvm.org/">Bug Reports</a>
     <a href="http://planet.clang.org/">Planet Clang</a>
     <a href="irc://irc.oftc.net/llvm">IRC: irc.oftc.net#llvm</a>
   </div>
 
   <div class="submenu">
     <label>The Code</label>
-    <a href="/get_started.html#build">Check Out SVN</a>
-    <a href="http://llvm.org/svn/llvm-project/cfe/trunk/">Browse SVN</a>
-    <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/">Browse ViewVC</a>
+    <a href="/get_started.html#build">Check Out Sources</a>
+    <a href="https://github.com/llvm/llvm-project/tree/master/clang/">Browse Sources</a>
     <a href="http://clang.llvm.org/doxygen/">doxygen</a>
   </div>
 
   <div class="submenu">
     <label>Quick Links</label>
     <a href="http://llvm.org/reports/coverage/">Testing Coverage</a>
   </div>
 
   <div class="submenu">
     <label>Clang Events</label>
     <a href="http://llvm.org/devmtg/">LLVM Meeting</a>
   </div>
 
 </div>