[Documentation] Use HTTPS whenever possible in Clang

[sylvestre.ledru]

Did you test all url?

[Eugene.Zelenko]

Yes, I tested all URLs, but I think independent testing will not be excessive.

[hans]

Seems like a good change to me.

cfe/trunk/docs/AutomaticReferenceCounting.rst

 .. FIXME: move to the stylesheet or Sphinx plugin
 
 .. raw:: html
 
   <style>
     .arc-term { font-style: italic; font-weight: bold; }
     .revision { font-style: italic; }
     .when-revised { font-weight: bold; font-style: normal; }
 
     /*
      * Automatic numbering is described in this article:
-     * http://dev.opera.com/articles/view/automatic-numbering-with-css-counters/
+     * https://dev.opera.com/articles/view/automatic-numbering-with-css-counters/
      */
     /*
      * Automatic numbering for the TOC.
      * This is wrong from the semantics point of view, since it is an ordered
      * list, but uses "ul" tag.
      */
     div#contents.contents.local ul {
       counter-reset: toc-section;

cfe/trunk/docs/ClangFormatStyleOptions.rst

**BasedOnStyle** (``string``)
   * ``LLVM``
     A style complying with the `LLVM coding standards
     <https://llvm.org/docs/CodingStandards.html>`_
   * ``Google``
     A style complying with `Google's C++ style guide
     <http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml>`_
   * ``Chromium``
     A style complying with `Chromium's style guide
-    <http://www.chromium.org/developers/coding-style>`_
+    <https://www.chromium.org/developers/coding-style>`_
   * ``Mozilla``
     A style complying with `Mozilla's style guide
     <https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style>`_
   * ``WebKit``
     A style complying with `WebKit's style guide
-    <http://www.webkit.org/coding/coding-style.html>`_
+    <https://www.webkit.org/coding/coding-style.html>`_
 
 .. START_FORMAT_STYLE_OPTIONS
 
 **AccessModifierOffset** (``int``)
   The extra indent or outdent of access modifiers, e.g. ``public:``.
 
 **AlignAfterOpenBracket** (``BracketAlignmentStyle``)
   If ``true``, horizontally aligns arguments after an open bracket.

 
 
 
 **IncludeCategories** (``std::vector<IncludeCategory>``)
   Regular expressions denoting the different ``#include`` categories
   used for ordering ``#includes``.
 
   `POSIX extended
-  <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html>`_
+  <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html>`_
   regular expressions are supported.
 
   These regular expressions are matched against the filename of an include
   (including the <> or "") in order. The value belonging to the first
   matching regular expression is assigned and ``#includes`` are sorted first
   according to increasing category number and then alphabetically within
   each category.
 

cfe/trunk/docs/ControlFlowIntegrity.rst

 Design
 ======
 
 Please refer to the :doc:`design document<ControlFlowIntegrityDesign>`.
 
 Publications
 ============
 
-`Control-Flow Integrity: Principles, Implementations, and Applications <http://research.microsoft.com/pubs/64250/ccs05.pdf>`_.
+`Control-Flow Integrity: Principles, Implementations, and Applications <https://research.microsoft.com/pubs/64250/ccs05.pdf>`_.
 Martin Abadi, Mihai Budiu, Úlfar Erlingsson, Jay Ligatti.
 
 `Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM <http://www.pcc.me.uk/~peter/acad/usenix14.pdf>`_.
 Caroline Tice, Tom Roeder, Peter Collingbourne, Stephen Checkoway,
 Úlfar Erlingsson, Luis Lozano, Geoff Pike.

cfe/trunk/docs/ControlFlowIntegrityDesign.rst

.. code-block:: none
   ca7fec:       ff 91 98 00 00 00       callq  *0x98(%rcx)
     [...]
   ca8511:       0f 0b                   ud2
 
 The compiler relies on co-operation from the linker in order to assemble
 the bit vectors for the whole program. It currently does this using LLVM's
 `type metadata`_ mechanism together with link-time optimization.
 
-.. _address point: http://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-general
+.. _address point: https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-general
 .. _type metadata: https://llvm.org/docs/TypeMetadata.html
 .. _ByteArrayBuilder: https://llvm.org/docs/doxygen/html/structllvm_1_1ByteArrayBuilder.html
 
 Optimizations
 -------------
 
 The scheme as described above is the fully general variant of the scheme.
 Most of the time we are able to apply one or more of the following

 ---------
 
 RCFI does not protect `RET` instructions:
   * in non-instrumented DSOs,
   * in instrumented DSOs for functions that are called from non-instrumented DSOs,
   * embedded into other instructions (e.g. `0f4fc3 cmovg %ebx,%eax`).
 
 .. _SafeStack: https://clang.llvm.org/docs/SafeStack.html
-.. _RFG: http://xlab.tencent.com/en/2016/11/02/return-flow-guard
+.. _RFG: https://xlab.tencent.com/en/2016/11/02/return-flow-guard
 .. _Intel CET: https://software.intel.com/en-us/blogs/2016/06/09/intel-release-new-technology-specifications-protect-rop-attacks
 
 Hardware support
 ================
 
 We believe that the above design can be efficiently implemented in hardware.
 A single new instruction added to an ISA would allow to perform the forward-edge CFI check
 with fewer bytes per check (smaller code size overhead) and potentially more

cfe/trunk/docs/ExternalClangExamples.rst

 better serve our external users. Some typical categories of applications
 where Clang is used are:
 
 - Static analysis.
 - Documentation/cross-reference generation.
 
 If you know of (or wrote!) a tool or project using Clang, please send an
 email to Clang's `development discussion mailing list
-<http://lists.llvm.org/mailman/listinfo/cfe-dev>`_ to have it added.
+<https://lists.llvm.org/mailman/listinfo/cfe-dev>`_ to have it added.
 (or if you are already a Clang contributor, feel free to directly commit
 additions). Since the primary purpose of this page is to provide examples
 that can help developers, generally they must have code available.
 
 List of projects and tools
 ==========================
 
 `<https://github.com/Andersbakken/rtags/>`_
    "RTags is a client/server application that indexes c/c++ code and keeps
    a persistent in-memory database of references, symbolnames, completions
    etc."
 
-`<http://rprichard.github.com/sourceweb/>`_
+`<https://rprichard.github.com/sourceweb/>`_
    "A C/C++ source code indexer and navigator"
 
 `<https://github.com/etaoins/qconnectlint>`_
    "qconnectlint is a Clang tool for statically verifying the consistency
    of signal and slot connections made with Qt's ``QObject::connect``."
 
 `<https://github.com/woboq/woboq_codebrowser>`_
    "The Woboq Code Browser is a web-based code browser for C/C++ projects.
-   Check out `<http://code.woboq.org/>`_ for an example!"
+   Check out `<https://code.woboq.org/>`_ for an example!"
 
 `<https://github.com/mozilla/dxr>`_
     "DXR is a source code cross-reference tool that uses static analysis
     data collected by instrumented compilers."
 
 `<https://github.com/eschulte/clang-mutate>`_
     "This tool performs a number of operations on C-language source files."
 

cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst

 * `SPARC ADI`_ implements a similar tool mostly in hardware.
 * `Effective and Efficient Memory Protection Using Dynamic Tainting`_ discusses
   similar approaches ("lock & key").
 * `Watchdog`_ discussed a heavier, but still somewhat similar
   "lock & key" approach.
 * *TODO: add more "related work" links. Suggestions are welcome.*
 
 
-.. _Watchdog: http://www.cis.upenn.edu/acg/papers/isca12_watchdog.pdf
+.. _Watchdog: https://www.cis.upenn.edu/acg/papers/isca12_watchdog.pdf
 .. _Effective and Efficient Memory Protection Using Dynamic Tainting: https://www.cc.gatech.edu/~orso/papers/clause.doudalis.orso.prvulovic.pdf
 .. _SPARC ADI: https://lazytyped.blogspot.com/2017/09/getting-started-with-adi.html
 .. _AddressSanitizer paper: https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
 .. _Address Tagging: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/ch12s05s01.html
 

cfe/trunk/docs/HowToSetupToolingForLLVM.rst

 using a command line parameter ``-p`` or let Clang Tooling find this
 file in your source tree. In either case you need to configure your
 build using CMake to use clang tools.
 
 Setup Clang Tooling Using CMake and Make
 ========================================
 
 If you intend to use make to build LLVM, you should have CMake 2.8.6 or
-later installed (can be found `here <http://cmake.org>`_).
+later installed (can be found `here <https://cmake.org>`_).
 
 First, you need to generate Makefiles for LLVM with CMake. You need to
 make a build directory and run CMake from it:
 
 .. code-block:: console
 
   $ mkdir your/build/directory
   $ cd your/build/directory

cfe/trunk/docs/InternalsManual.rst

 correctly.  If it is ever incorrect, the front-end may get confused and die.
 The reason for this is that the notion of the "spelling" of a ``Token`` in
 Clang depends on being able to find the original input characters for the
 token.  This concept maps directly to the "spelling location" for the token.
 
 ``SourceRange`` and ``CharSourceRange``
 ---------------------------------------
 
-.. mostly taken from http://lists.llvm.org/pipermail/cfe-dev/2010-August/010595.html
+.. mostly taken from https://lists.llvm.org/pipermail/cfe-dev/2010-August/010595.html
 
 Clang represents most source ranges by [first, last], where "first" and "last"
 each point to the beginning of their respective tokens.  For example consider
 the ``SourceRange`` of the following statement:
 
 .. code-block:: text
 
   x = foo + bar;

 -----------------
 
 The ``CFG`` class is designed to represent a source-level control-flow graph
 for a single statement (``Stmt*``).  Typically instances of ``CFG`` are
 constructed for function bodies (usually an instance of ``CompoundStmt``), but
 can also be instantiated to represent the control-flow of any class that
 subclasses ``Stmt``, which includes simple expressions.  Control-flow graphs
 are especially useful for performing `flow- or path-sensitive
-<http://en.wikipedia.org/wiki/Data_flow_analysis#Sensitivities>`_ program
+<https://en.wikipedia.org/wiki/Data_flow_analysis#Sensitivities>`_ program
 analyses on a given function.
 
 Basic Blocks
 ^^^^^^^^^^^^
 
 Concretely, an instance of ``CFG`` is a collection of basic blocks.  Each basic
 block is an instance of ``CFGBlock``, which simply contains an ordered sequence
 of ``Stmt*`` (each referring to statements in the AST).  The ordering of

cfe/trunk/docs/IntroductionToTheClangAST.rst

 =============================
 Introduction to the Clang AST
 =============================
 
 This document gives a gentle introduction to the mysteries of the Clang
 AST. It is targeted at developers who either want to contribute to
 Clang, or use tools that work based on Clang's AST, like the AST
 matchers.
 
 .. raw:: html
 
-  <center><iframe width="560" height="315" src="http://www.youtube.com/embed/VqCkCDFLSsc?vq=hd720" frameborder="0" allowfullscreen></iframe></center>
+  <center><iframe width="560" height="315" src="https://www.youtube.com/embed/VqCkCDFLSsc?vq=hd720" frameborder="0" allowfullscreen></iframe></center>
 
 `Slides <https://llvm.org/devmtg/2013-04/klimek-slides.pdf>`_
 
 Introduction
 ============
 
 Clang's AST is different from ASTs produced by some other compilers in
 that it closely resembles both the written C++ code and the C++

cfe/trunk/docs/JSONCompilationDatabase.rst

-  Build systems are inherently sequential in the build graph, for
    independently of the build still need the generated source code to
    exist, running tools multiple times over unchanging source does not
    require serialization of the runs according to the build dependency
    graph.
 
 Supported Systems
 =================
 
-Currently `CMake <http://cmake.org>`_ (since 2.8.5) supports generation
+Currently `CMake <https://cmake.org>`_ (since 2.8.5) supports generation
 of compilation databases for Unix Makefile builds (Ninja builds in the
 works) with the option ``CMAKE_EXPORT_COMPILE_COMMANDS``.
 
 For projects on Linux, there is an alternative to intercept compiler
 calls with a tool called `Bear <https://github.com/rizsotto/Bear>`_.
 
 Clang's tooling interface supports reading compilation databases; see
 the :doc:`LibTooling documentation <LibTooling>`. libclang and its

cfe/trunk/docs/LanguageExtensions.rst

.. toctree::
    AutomaticReferenceCounting
 
 Introduction
 ============
 
 This document describes the language extensions provided by Clang.  In addition
 to the language extensions listed here, Clang aims to support a broad range of
 GCC extensions.  Please see the `GCC manual
-<http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html>`_ for more information on
+<https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html>`_ for more information on
 these extensions.
 
 .. _langext-feature_check:
 
 Feature Checking Macros
 =======================
 
 Language extensions can be very useful, but only if you know you can depend on

 implementation-defined and subject to change -- as such they're tied closely to
 the supported set of system headers, currently:
 
 * LLVM's own libc++
 * GNU libstdc++
 * The Microsoft standard C++ library
 
 Clang supports the `GNU C++ type traits
-<http://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html>`_ and a subset of the
+<https://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html>`_ and a subset of the
 `Microsoft Visual C++ Type traits
-<http://msdn.microsoft.com/en-us/library/ms177194(v=VS.100).aspx>`_.
+<https://msdn.microsoft.com/en-us/library/ms177194(v=VS.100).aspx>`_.
 
 Feature detection is supported only for some of the primitives at present. User
 code should not use these checks because they bear no direct relation to the
 actual set of type traits supported by the C++ standard library.
 
 For type trait ``__X``, ``__has_extension(X)`` indicates the presence of the
 type trait primitive in the compiler. A simplistic usage example as might be
 seen in standard C++ headers follows:

 
 .. _langext-objc-retain-release:
 
 Objective-C retaining behavior attributes
 -----------------------------------------
 
 In Objective-C, functions and methods are generally assumed to follow the
 `Cocoa Memory Management 
-<http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html>`_
+<https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html>`_
 conventions for ownership of object arguments and
 return values. However, there are exceptions, and so Clang provides attributes
 to allow these exceptions to be documented. This are used by ARC and the
 `static analyzer <https://clang-analyzer.llvm.org>`_ Some exceptions may be
 better described using the ``objc_method_family`` attribute instead.
 
 **Usage**: The ``ns_returns_retained``, ``ns_returns_not_retained``,
 ``ns_returns_autoreleased``, ``cf_returns_retained``, and

 C++ Coroutines support builtins
 --------------------------------
 
 .. warning::
   This is a work in progress. Compatibility across Clang/LLVM releases is not 
   guaranteed.
 
 Clang provides experimental builtins to support C++ Coroutines as defined by
-http://wg21.link/P0057. The following four are intended to be used by the
+https://wg21.link/P0057. The following four are intended to be used by the
 standard library to implement `std::experimental::coroutine_handle` type.
 
 **Syntax**:
 
 .. code-block:: c
 
   void  __builtin_coro_resume(void *addr);
   void  __builtin_coro_destroy(void *addr);

 
 Clang's non-standard C++11 attributes live in the ``clang`` attribute
 namespace.
 
 Clang supports GCC's ``gnu`` attribute namespace. All GCC attributes which
 are accepted with the ``__attribute__((foo))`` syntax are also accepted as
 ``[[gnu::foo]]``. This only extends to attributes which are specified by GCC
 (see the list of `GCC function attributes
-<http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>`_, `GCC variable
-attributes <http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html>`_, and
+<https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>`_, `GCC variable
+attributes <https://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html>`_, and
 `GCC type attributes
-<http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html>`_). As with the GCC
+<https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html>`_). As with the GCC
 implementation, these attributes must appertain to the *declarator-id* in a
 declaration, which means they must go either at the start of the declaration or
 immediately after the name being declared.
 
 For example, this applies the GNU ``unused`` attribute to ``a`` and ``f``, and
 also applies the GNU ``noreturn`` attribute to ``f``.
 
 .. code-block:: c++

cfe/trunk/docs/MSVCCompatibility.rst

 
 * Member pointers: :good:`Mostly complete`.  Standard C++ member pointers are
   fully implemented and should be ABI compatible.  Both `#pragma
   pointers_to_members`_ and the `/vm`_ flags are supported. However, MSVC
   supports an extension to allow creating a `pointer to a member of a virtual
   base class`_.  Clang does not yet support this.
 
 .. _#pragma pointers_to_members:
-  http://msdn.microsoft.com/en-us/library/83cch5a6.aspx
-.. _/vm: http://msdn.microsoft.com/en-us/library/yad46a6z.aspx
+  https://msdn.microsoft.com/en-us/library/83cch5a6.aspx
+.. _/vm: https://msdn.microsoft.com/en-us/library/yad46a6z.aspx
 .. _pointer to a member of a virtual base class: https://llvm.org/PR15713
 
 * Debug info: :good:`Mostly complete`.  Clang emits relatively complete CodeView
   debug information if ``/Z7`` or ``/Zi`` is passed. Microsoft's link.exe will
   transform the CodeView debug information into a PDB that works in Windows
   debuggers and other tools that consume PDB files like ETW. Work to teach lld
   about CodeView and PDBs is ongoing.
 

cfe/trunk/docs/PCHInternals.rst

 As with types and declarations, each statement and expression kind in Clang's
 abstract syntax tree (``ForStmt``, ``CallExpr``, etc.) has a corresponding
 record type in the AST file, which contains the serialized representation of
 that statement or expression.  Each substatement or subexpression within an
 expression is stored as a separate record (which keeps most records to a fixed
 size).  Within the AST file, the subexpressions of an expression are stored, in
 reverse order, prior to the expression that owns those expression, using a form
 of `Reverse Polish Notation
-<http://en.wikipedia.org/wiki/Reverse_Polish_notation>`_.  For example, an
+<https://en.wikipedia.org/wiki/Reverse_Polish_notation>`_. For example, an
 expression ``3 - 4 + 5`` would be represented as follows:
 
 +-----------------------+
 | ``IntegerLiteral(5)`` |
 +-----------------------+
 | ``IntegerLiteral(4)`` |
 +-----------------------+
 | ``IntegerLiteral(3)`` |

cfe/trunk/docs/SafeStack.rst

 overhead. It works by separating the program stack into two distinct regions:
 the safe stack and the unsafe stack. The safe stack stores return addresses,
 register spills, and local variables that are always accessed in a safe way,
 while the unsafe stack stores everything else. This separation ensures that
 buffer overflows on the unsafe stack cannot be used to overwrite anything
 on the safe stack.
 
 SafeStack is a part of the `Code-Pointer Integrity (CPI) Project
-<http://dslab.epfl.ch/proj/cpi/>`_.
+<https://dslab.epfl.ch/proj/cpi/>`_.
 
 Performance
 -----------
 
 The performance overhead of the SafeStack instrumentation is less than 0.1% on
 average across a variety of benchmarks (see the `Code-Pointer Integrity
-<http://dslab.epfl.ch/pubs/cpi.pdf>`__ paper for details). This is mainly
+<https://dslab.epfl.ch/pubs/cpi.pdf>`_ paper for details). This is mainly
 because most small functions do not have any variables that require the unsafe
 stack and, hence, do not need unsafe stack frames to be created. The cost of
 creating unsafe stack frames for large functions is amortized by the cost of
 executing the function.
 
 In some cases, SafeStack actually improves the performance. Objects that end up
 being moved to the unsafe stack are usually large arrays or variables that are
 used through multiple stack frames. Moving such objects away from the safe

 ever stored outside of the safe stack itself (see limitations below).
 
 Known security limitations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A complete protection against control-flow hijack attacks requires combining
 SafeStack with another mechanism that enforces the integrity of code pointers
 that are stored on the heap or the unsafe stack, such as `CPI
-<http://dslab.epfl.ch/proj/cpi/>`_, or a forward-edge control flow integrity
+<https://dslab.epfl.ch/proj/cpi/>`_, or a forward-edge control flow integrity
 mechanism that enforces correct calling conventions at indirect call sites,
-such as `IFCC <http://research.google.com/pubs/archive/42808.pdf>`_ with arity
+such as `IFCC <https://research.google.com/pubs/archive/42808.pdf>`_ with arity
 checks. Clang has control-flow integrity protection scheme for :doc:`C++ virtual
 calls <ControlFlowIntegrity>`, but not non-virtual indirect calls. With
 SafeStack alone, an attacker can overwrite a function pointer on the heap or
 the unsafe stack and cause a program to call arbitrary location, which in turn
 might enable stack pivoting and return-oriented programming.
 
 In its current implementation, SafeStack provides precise protection against
 stack-based buffer overflows, but protection against arbitrary memory write
 vulnerabilities is probabilistic and relies on randomization and information
 hiding. The randomization is currently based on system-enforced ASLR and shares
 its known security limitations. The safe stack pointer hiding is not perfect
 yet either: system library functions such as ``swapcontext``, exception
 handling mechanisms, intrinsics such as ``__builtin_frame_address``, or
 low-level bugs in runtime support could leak the safe stack pointer. In the
 future, such leaks could be detected by static or dynamic analysis tools and
 prevented by adjusting such functions to either encrypt the stack pointer when
 storing it in the heap (as already done e.g., by ``setjmp``/``longjmp``
 implementation in glibc), or store it in a safe region instead.
 
-The `CPI paper <http://dslab.epfl.ch/pubs/cpi.pdf>`_ describes two alternative,
+The `CPI paper <https://dslab.epfl.ch/pubs/cpi.pdf>`_ describes two alternative,
 stronger safe stack protection mechanisms, that rely on software fault
 isolation, or hardware segmentation (as available on x86-32 and some x86-64
 CPUs).
 
 At the moment, SafeStack assumes that the compiler's implementation is correct.
 This has not been verified except through manual code inspection, and could
 always regress in the future. It's therefore desirable to have a separate
 static or dynamic binary verification tool that would check the correctness of

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Deprecated: This builtin function is an alias for
 ``__builtin___get_unsafe_stack_bottom()``.
 
 Design
 ======
 
-Please refer to the `Code-Pointer Integrity <http://dslab.epfl.ch/proj/cpi/>`__
+Please refer to the `Code-Pointer Integrity <https://dslab.epfl.ch/proj/cpi/>`_
 project page for more information about the design of the SafeStack and its
 related technologies.
 
 setjmp and exception handling
 -----------------------------
 
-The `OSDI'14 paper <http://dslab.epfl.ch/pubs/cpi.pdf>`_ mentions that
+The `OSDI'14 paper <https://dslab.epfl.ch/pubs/cpi.pdf>`_ mentions that
 on Linux the instrumentation pass finds calls to setjmp or functions that
 may throw an exception, and inserts required instrumentation at their call
 sites. Specifically, the instrumentation pass saves the shadow stack pointer
 on the safe stack before the call site, and restores it either after the
 call to setjmp or after an exception has been caught. This is implemented
 in the function ``SafeStack::createStackRestorePoints``.
 
 Publications
 ------------
 
-`Code-Pointer Integrity <http://dslab.epfl.ch/pubs/cpi.pdf>`__.
+`Code-Pointer Integrity <https://dslab.epfl.ch/pubs/cpi.pdf>`_.
 Volodymyr Kuznetsov, Laszlo Szekeres, Mathias Payer, George Candea, R. Sekar, Dawn Song.
 USENIX Symposium on Operating Systems Design and Implementation
 (`OSDI <https://www.usenix.org/conference/osdi14>`_), Broomfield, CO, October 2014

cfe/trunk/docs/SanitizerCoverage.rst

.. code-block:: none
     |  B
     | /
     |/
     C
 
 If blocks A, B, and C are all covered we know for certain that the edges A=>B
 and B=>C were executed, but we still don't know if the edge A=>C was executed.
 Such edges of control flow graph are called
-`critical <http://en.wikipedia.org/wiki/Control_flow_graph#Special_edges>`_. The
-edge-level coverage simply splits all critical
-edges by introducing new dummy blocks and then instruments those blocks:
+`critical <https://en.wikipedia.org/wiki/Control_flow_graph#Special_edges>`_.
+The edge-level coverage simply splits all critical edges by introducing new
+dummy blocks and then instruments those blocks:
 
 .. code-block:: none
 
     A
     |\
     | \
     D  B
     | /

cfe/trunk/docs/Toolchain.rst

 
 Linker
 ------
 
 Clang can be configured to use one of several different linkers:
 
 * GNU ld
 * GNU gold
-* LLVM's `lld <http://lld.llvm.org>`_
+* LLVM's `lld <https://lld.llvm.org>`_
 * MSVC's link.exe
 
 Link-time optimization is natively supported by lld, and supported via
 a `linker plugin <https://llvm.org/docs/GoldPlugin.html>`_ when using gold.
 
 The default linker varies between targets, and can be overridden via the
 ``-fuse-ld=<linker name>`` flag.
 

 
 The default runtime library is target-specific. For targets where GCC is
 the dominant compiler, Clang currently defaults to using libgcc_s. On most
 other targets, compiler-rt is used by default.
 
 compiler-rt (LLVM)
 ^^^^^^^^^^^^^^^^^^
 
-`LLVM's compiler runtime library <http://compiler-rt.llvm.org/>`_ provides a
+`LLVM's compiler runtime library <https://compiler-rt.llvm.org/>`_ provides a
 complete set of runtime library functions containing all functions that
 Clang will implicitly call, in ``libclang_rt.builtins.<arch>.a``.
 
 You can instruct Clang to use compiler-rt with the ``--rtlib=compiler-rt`` flag.
 This is not supported on every platform.
 
 If using libc++ and/or libc++abi, you may need to configure them to use
 compiler-rt rather than libgcc_s by passing ``-DLIBCXX_USE_COMPILER_RT=YES``
.. note::
   configuration when using non-native atomic operations (if you see link errors
   referring to ``__atomic_*`` functions).
 
 Unwind library
 --------------
 
 The unwind library provides a family of ``_Unwind_*`` functions implementing
 the language-neutral stack unwinding portion of the Itanium C++ ABI
-(`Level I <http://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#base-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:
 

 
 libgcc_s has an integrated unwinder, and does not need an external unwind
 library to be provided.
 
 libunwind (nongnu.org)
 ^^^^^^^^^^^^^^^^^^^^^^
 
 This is another implementation of the libunwind specification.
-See `libunwind (nongnu.org) <http://www.nongnu.org/libunwind>`_.
+See `libunwind (nongnu.org) <https://www.nongnu.org/libunwind>`_.
 
 libunwind (PathScale)
 ^^^^^^^^^^^^^^^^^^^^^
 
 This is another implementation of the libunwind specification.
 See `libunwind (pathscale) <https://github.com/pathscale/libunwind>`_.
 
 Sanitizer runtime
 -----------------
 
 The instrumentation added by Clang's sanitizers (``-fsanitize=...``) implicitly
 makes calls to a runtime library, in order to maintain side state about the
 execution of the program and to issue diagnostic messages when a problem is
 detected.
 
 The only supported implementation of these runtimes is provided by LLVM's
 compiler-rt, and the relevant portion of that library
 (``libclang_rt.<sanitizer>.<arch>.a``)
 will be implicitly linked when linking with a ``-fsanitize=...`` flag.
 
 C standard library
 ------------------
 
 Clang supports a wide variety of
-`C standard library <http://en.cppreference.com/w/c>`_
+`C standard library <https://en.cppreference.com/w/c>`_
 implementations.
 
 C++ ABI library
 ---------------
 
 The C++ ABI library provides an implementation of the library portion of
 the Itanium C++ ABI, covering both the
 `support functionality in the main Itanium C++ ABI document
-<http://itanium-cxx-abi.github.io/cxx-abi/abi.html>`_ and
+<https://itanium-cxx-abi.github.io/cxx-abi/abi.html>`_ and
 `Level II of the exception handling support
-<http://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#cxx-abi>`_.
+<https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#cxx-abi>`_.
 References to the functions and objects in this library are implicitly
 generated by Clang when compiling C++ code.
 
 While it is possible to link C++ code using libstdc++ and code using libc++
 together into the same program (so long as you do not attempt to pass C++
 standard library objects across the boundary), it is not generally possible
 to have more than one C++ ABI library in a program.
 
 The version of the C++ ABI library used by Clang will be the one that the
 chosen C++ standard library was linked against. Several implementations are
 available:
 
 libc++abi (LLVM)
 ^^^^^^^^^^^^^^^^
 
-`libc++abi <http://libcxxabi.llvm.org/>`_ is LLVM's implementation of this
+`libc++abi <https://libcxxabi.llvm.org/>`_ is LLVM's implementation of this
 specification.
 
 libsupc++ (GNU)
 ^^^^^^^^^^^^^^^
 
 libsupc++ is GCC's implementation of this specification. However, this
 library is only used when libstdc++ is linked statically. The dynamic
 library version of libstdc++ contains a copy of libsupc++.

 
 This is another implementation of the Itanium C++ ABI specification.
 See `libcxxrt <https://github.com/pathscale/libcxxrt>`_.
 
 C++ standard library
 --------------------
 
 Clang supports use of either LLVM's libc++ or GCC's libstdc++ implementation
-of the `C++ standard library <http://en.cppreference.com/w/cpp>`_.
+of the `C++ standard library <https://en.cppreference.com/w/cpp>`_.
 
 libc++ (LLVM)
 ^^^^^^^^^^^^^
 
-`libc++ <http://libcxx.llvm.org/>`_ is LLVM's implementation of the C++
+`libc++ <https://libcxx.llvm.org/>`_ is LLVM's implementation of the C++
 standard library, aimed at being a complete implementation of the C++
 standards from C++11 onwards.
 
 You can instruct Clang to use libc++ with the ``-stdlib=libc++`` flag.
 
 libstdc++ (GNU)
 ^^^^^^^^^^^^^^^
 
 `libstdc++ <https://gcc.gnu.org/onlinedocs/libstdc++/>`_ is GCC's implementation
 of the C++ standard library. Clang supports a wide range of versions of
 libstdc++, from around version 4.2 onwards, and will implicitly work around
 some bugs in older versions of libstdc++.
 
 You can instruct Clang to use libstdc++ with the ``-stdlib=libstdc++`` flag.

cfe/trunk/docs/UndefinedBehaviorSanitizer.rst

 More Information
 ================
 
 * From LLVM project blog:
   `What Every C Programmer Should Know About Undefined Behavior
   <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>`_
 * From John Regehr's *Embedded in Academia* blog:
   `A Guide to Undefined Behavior in C and C++
-  <http://blog.regehr.org/archives/213>`_
+  <https://blog.regehr.org/archives/213>`_

cfe/trunk/docs/UsersManual.rst

 Introduction
 ============
 
 The Clang Compiler is an open-source compiler for the C family of
 programming languages, aiming to be the best in class implementation of
 these languages. Clang builds on the LLVM optimizer and code generator,
 allowing it to provide high-quality optimization and code generation
 support for many targets. For more general information, please see the
-`Clang Web Site <http://clang.llvm.org>`_ or the `LLVM Web
-Site <http://llvm.org>`_.
+`Clang Web Site <https://clang.llvm.org>`_ or the `LLVM Web
+Site <https://llvm.org>`_.
 
 This document describes important notes about using Clang as a compiler
 for an end-user, documenting the supported features, command line
 options, etc. If you are interested in using Clang to build a tool that
 processes code, please see :doc:`InternalsManual`. If you are interested in the
 `Clang Static Analyzer <https://clang-analyzer.llvm.org>`_, please see its web
 page.
 

 page <https://clang-analyzer.llvm.org/faq.html#exclude_code>`_ for more
 information.
 
 .. _usersmanual-precompiled-headers:
 
 Precompiled Headers
 -------------------
 
-`Precompiled headers <http://en.wikipedia.org/wiki/Precompiled_header>`__
+`Precompiled headers <https://en.wikipedia.org/wiki/Precompiled_header>`_
 are a general approach employed by many compilers to reduce compilation
 time. The underlying motivation of the approach is that it is common for
 the same (and often large) header files to be included by multiple
 source files. Consequently, compile times can often be greatly improved
 by caching some of the (redundant) work done by a compiler to process
 headers. Precompiled header files, which represent one of many ways to
 implement this optimization, are literally files that represent an
 on-disk cache that contains the vital information necessary to reduce
2. Run the executable under a sampling profiler. The specific profiler
 
    Note the use of the ``-b`` flag. This tells Perf to use the Last Branch
    Record (LBR) to record call chains. While this is not strictly required,
    it provides better call information, which improves the accuracy of
    the profile data.
 
 3. Convert the collected profile data to LLVM's sample profile format.
    This is currently supported via the AutoFDO converter ``create_llvm_prof``.
-   It is available at http://github.com/google/autofdo. Once built and
+   It is available at https://github.com/google/autofdo. Once built and
    installed, you can convert the ``perf.data`` file to LLVM using
    the command:
 
    .. code-block:: console
 
      $ create_llvm_prof --binary=./code --out=code.prof
 
    This will read ``perf.data`` and the binary file ``./code`` and emit

 
 1. ASCII text. This is the easiest one to generate. The file is divided into
    sections, which correspond to each of the functions with profile
    information. The format is described below. It can also be generated from
    the binary or gcov formats using the ``llvm-profdata`` tool.
 
 2. Binary encoding. This uses a more efficient encoding that yields smaller
    profile files. This is the format generated by the ``create_llvm_prof`` tool
-   in http://github.com/google/autofdo.
+   in https://github.com/google/autofdo.
 
 3. GCC encoding. This is based on the gcov format, which is accepted by GCC. It
    is only interesting in environments where GCC and Clang co-exist. This
    encoding is only generated by the ``create_gcov`` tool in
-   http://github.com/google/autofdo. It can be read by LLVM and
+   https://github.com/google/autofdo. It can be read by LLVM and
    ``llvm-profdata``, but it cannot be generated by either.
 
 If you are using Linux Perf to generate sampling profiles, you can use the
 conversion tool ``create_llvm_prof`` described in the previous section.
 Otherwise, you will need to write a conversion tool that converts your
 profiler's native format into one of these three.
 
 

 The profile remapping file is a text file containing lines of the form
 
 .. code-block:: text
 
   fragmentkind fragment1 fragment2
 
 where ``fragmentkind`` is one of ``name``, ``type``, or ``encoding``,
 indicating whether the following mangled name fragments are
-<`name <http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.name>`_>s,
-<`type <http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.type>`_>s, or
-<`encoding <http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.encoding>`_>s,
+<`name <https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.name>`_>s,
+<`type <https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.type>`_>s, or
+<`encoding <https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.encoding>`_>s,
 respectively.
 Blank lines and lines starting with ``#`` are ignored.
 
 For convenience, built-in <substitution>s such as ``St`` and ``Ss``
 are accepted as <name>s (even though they technically are not <name>s).
 
 For example, to specify that ``absl::string_view`` and ``std::string_view``
 should be treated as equivalent when matching profile data, the following

 ========
 
 clang-cl is an alternative command-line interface to Clang, designed for
 compatibility with the Visual C++ compiler, cl.exe.
 
 To enable clang-cl to find system headers, libraries, and the linker when run
 from the command-line, it should be executed inside a Visual Studio Native Tools
 Command Prompt or a regular Command Prompt where the environment has been set
-up using e.g. `vcvarsall.bat <http://msdn.microsoft.com/en-us/library/f2ccy3wt.aspx>`_.
+up using e.g. `vcvarsall.bat <https://msdn.microsoft.com/en-us/library/f2ccy3wt.aspx>`_.
 
 clang-cl can also be used from inside Visual Studio by selecting the LLVM
 Platform Toolset. The toolset is not part of the installer, but may be installed
 separately from the
 `Visual Studio Marketplace <https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain>`_.
 To use the toolset, select a project in Solution Explorer, open its Property
 Page (Alt+F7), and in the "General" section of "Configuration Properties"
 change "Platform Toolset" to LLVM.  Doing so enables an additional Property

cfe/trunk/docs/analyzer/DesignDiscussions/InitializerLists.rst

 
 Nope, this approach is wrong. Metadata symbols may become out-of-date: when the
 object changes, metadata symbols attached to it aren't changing (because symbols
 simply don't change). The same metadata may have different symbols to denote its
 value in different moments of time, but at most one of them represents the
 actual metadata value. So we'd be escaping more stuff than necessary.
 
 If only we had "ghost fields"
-(http://lists.llvm.org/pipermail/cfe-dev/2016-May/049000.html), it would have
+(https://lists.llvm.org/pipermail/cfe-dev/2016-May/049000.html), it would have
 been much easier, because the ghost field would only contain the actual
 metadata, and the Store would always know about it. This example adds to my
 belief that ghost fields are exactly what we need for most C++ checkers.
 
 **Devin:**
 
 In this case, I would be fine with some sort of
 AbstractStorageMemoryRegion that meant "here is a memory region and somewhere