[www-releases] r331981 - Add 5.0.2 docs and update download.html
Tom Stellard via llvm-commits
llvm-commits at lists.llvm.org
Thu May 10 06:54:19 PDT 2018
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/InternalsManual.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/InternalsManual.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/InternalsManual.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/InternalsManual.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,2096 @@
+============================
+"Clang" CFE Internals Manual
+============================
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+This document describes some of the more important APIs and internal design
+decisions made in the Clang C front-end. The purpose of this document is to
+both capture some of this high level information and also describe some of the
+design decisions behind it. This is meant for people interested in hacking on
+Clang, not for end-users. The description below is categorized by libraries,
+and does not describe any of the clients of the libraries.
+
+LLVM Support Library
+====================
+
+The LLVM ``libSupport`` library provides many underlying libraries and
+`data-structures <http://llvm.org/docs/ProgrammersManual.html>`_, including
+command line option processing, various containers and a system abstraction
+layer, which is used for file system access.
+
+The Clang "Basic" Library
+=========================
+
+This library certainly needs a better name. The "basic" library contains a
+number of low-level utilities for tracking and manipulating source buffers,
+locations within the source buffers, diagnostics, tokens, target abstraction,
+and information about the subset of the language being compiled for.
+
+Part of this infrastructure is specific to C (such as the ``TargetInfo``
+class), other parts could be reused for other non-C-based languages
+(``SourceLocation``, ``SourceManager``, ``Diagnostics``, ``FileManager``).
+When and if there is future demand we can figure out if it makes sense to
+introduce a new library, move the general classes somewhere else, or introduce
+some other solution.
+
+We describe the roles of these classes in order of their dependencies.
+
+The Diagnostics Subsystem
+-------------------------
+
+The Clang Diagnostics subsystem is an important part of how the compiler
+communicates with the human. Diagnostics are the warnings and errors produced
+when the code is incorrect or dubious. In Clang, each diagnostic produced has
+(at the minimum) a unique ID, an English translation associated with it, a
+:ref:`SourceLocation <SourceLocation>` to "put the caret", and a severity
+(e.g., ``WARNING`` or ``ERROR``). They can also optionally include a number of
+arguments to the dianostic (which fill in "%0"'s in the string) as well as a
+number of source ranges that related to the diagnostic.
+
+In this section, we'll be giving examples produced by the Clang command line
+driver, but diagnostics can be :ref:`rendered in many different ways
+<DiagnosticClient>` depending on how the ``DiagnosticClient`` interface is
+implemented. A representative example of a diagnostic is:
+
+.. code-block:: text
+
+ t.c:38:15: error: invalid operands to binary expression ('int *' and '_Complex float')
+ P = (P-42) + Gamma*4;
+ ~~~~~~ ^ ~~~~~~~
+
+In this example, you can see the English translation, the severity (error), you
+can see the source location (the caret ("``^``") and file/line/column info),
+the source ranges "``~~~~``", arguments to the diagnostic ("``int*``" and
+"``_Complex float``"). You'll have to believe me that there is a unique ID
+backing the diagnostic :).
+
+Getting all of this to happen has several steps and involves many moving
+pieces, this section describes them and talks about best practices when adding
+a new diagnostic.
+
+The ``Diagnostic*Kinds.td`` files
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Diagnostics are created by adding an entry to one of the
+``clang/Basic/Diagnostic*Kinds.td`` files, depending on what library will be
+using it. From this file, :program:`tblgen` generates the unique ID of the
+diagnostic, the severity of the diagnostic and the English translation + format
+string.
+
+There is little sanity with the naming of the unique ID's right now. Some
+start with ``err_``, ``warn_``, ``ext_`` to encode the severity into the name.
+Since the enum is referenced in the C++ code that produces the diagnostic, it
+is somewhat useful for it to be reasonably short.
+
+The severity of the diagnostic comes from the set {``NOTE``, ``REMARK``,
+``WARNING``,
+``EXTENSION``, ``EXTWARN``, ``ERROR``}. The ``ERROR`` severity is used for
+diagnostics indicating the program is never acceptable under any circumstances.
+When an error is emitted, the AST for the input code may not be fully built.
+The ``EXTENSION`` and ``EXTWARN`` severities are used for extensions to the
+language that Clang accepts. This means that Clang fully understands and can
+represent them in the AST, but we produce diagnostics to tell the user their
+code is non-portable. The difference is that the former are ignored by
+default, and the later warn by default. The ``WARNING`` severity is used for
+constructs that are valid in the currently selected source language but that
+are dubious in some way. The ``REMARK`` severity provides generic information
+about the compilation that is not necessarily related to any dubious code. The
+``NOTE`` level is used to staple more information onto previous diagnostics.
+
+These *severities* are mapped into a smaller set (the ``Diagnostic::Level``
+enum, {``Ignored``, ``Note``, ``Remark``, ``Warning``, ``Error``, ``Fatal``}) of
+output
+*levels* by the diagnostics subsystem based on various configuration options.
+Clang internally supports a fully fine grained mapping mechanism that allows
+you to map almost any diagnostic to the output level that you want. The only
+diagnostics that cannot be mapped are ``NOTE``\ s, which always follow the
+severity of the previously emitted diagnostic and ``ERROR``\ s, which can only
+be mapped to ``Fatal`` (it is not possible to turn an error into a warning, for
+example).
+
+Diagnostic mappings are used in many ways. For example, if the user specifies
+``-pedantic``, ``EXTENSION`` maps to ``Warning``, if they specify
+``-pedantic-errors``, it turns into ``Error``. This is used to implement
+options like ``-Wunused_macros``, ``-Wundef`` etc.
+
+Mapping to ``Fatal`` should only be used for diagnostics that are considered so
+severe that error recovery won't be able to recover sensibly from them (thus
+spewing a ton of bogus errors). One example of this class of error are failure
+to ``#include`` a file.
+
+The Format String
+^^^^^^^^^^^^^^^^^
+
+The format string for the diagnostic is very simple, but it has some power. It
+takes the form of a string in English with markers that indicate where and how
+arguments to the diagnostic are inserted and formatted. For example, here are
+some simple format strings:
+
+.. code-block:: c++
+
+ "binary integer literals are an extension"
+ "format string contains '\\0' within the string body"
+ "more '%%' conversions than data arguments"
+ "invalid operands to binary expression (%0 and %1)"
+ "overloaded '%0' must be a %select{unary|binary|unary or binary}2 operator"
+ " (has %1 parameter%s1)"
+
+These examples show some important points of format strings. You can use any
+plain ASCII character in the diagnostic string except "``%``" without a
+problem, but these are C strings, so you have to use and be aware of all the C
+escape sequences (as in the second example). If you want to produce a "``%``"
+in the output, use the "``%%``" escape sequence, like the third diagnostic.
+Finally, Clang uses the "``%...[digit]``" sequences to specify where and how
+arguments to the diagnostic are formatted.
+
+Arguments to the diagnostic are numbered according to how they are specified by
+the C++ code that :ref:`produces them <internals-producing-diag>`, and are
+referenced by ``%0`` .. ``%9``. If you have more than 10 arguments to your
+diagnostic, you are doing something wrong :). Unlike ``printf``, there is no
+requirement that arguments to the diagnostic end up in the output in the same
+order as they are specified, you could have a format string with "``%1 %0``"
+that swaps them, for example. The text in between the percent and digit are
+formatting instructions. If there are no instructions, the argument is just
+turned into a string and substituted in.
+
+Here are some "best practices" for writing the English format string:
+
+* Keep the string short. It should ideally fit in the 80 column limit of the
+ ``DiagnosticKinds.td`` file. This avoids the diagnostic wrapping when
+ printed, and forces you to think about the important point you are conveying
+ with the diagnostic.
+* Take advantage of location information. The user will be able to see the
+ line and location of the caret, so you don't need to tell them that the
+ problem is with the 4th argument to the function: just point to it.
+* Do not capitalize the diagnostic string, and do not end it with a period.
+* If you need to quote something in the diagnostic string, use single quotes.
+
+Diagnostics should never take random English strings as arguments: you
+shouldn't use "``you have a problem with %0``" and pass in things like "``your
+argument``" or "``your return value``" as arguments. Doing this prevents
+:ref:`translating <internals-diag-translation>` the Clang diagnostics to other
+languages (because they'll get random English words in their otherwise
+localized diagnostic). The exceptions to this are C/C++ language keywords
+(e.g., ``auto``, ``const``, ``mutable``, etc) and C/C++ operators (``/=``).
+Note that things like "pointer" and "reference" are not keywords. On the other
+hand, you *can* include anything that comes from the user's source code,
+including variable names, types, labels, etc. The "``select``" format can be
+used to achieve this sort of thing in a localizable way, see below.
+
+Formatting a Diagnostic Argument
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Arguments to diagnostics are fully typed internally, and come from a couple
+different classes: integers, types, names, and random strings. Depending on
+the class of the argument, it can be optionally formatted in different ways.
+This gives the ``DiagnosticClient`` information about what the argument means
+without requiring it to use a specific presentation (consider this MVC for
+Clang :).
+
+Here are the different diagnostic argument formats currently supported by
+Clang:
+
+**"s" format**
+
+Example:
+ ``"requires %1 parameter%s1"``
+Class:
+ Integers
+Description:
+ This is a simple formatter for integers that is useful when producing English
+ diagnostics. When the integer is 1, it prints as nothing. When the integer
+ is not 1, it prints as "``s``". This allows some simple grammatical forms to
+ be to be handled correctly, and eliminates the need to use gross things like
+ ``"requires %1 parameter(s)"``.
+
+**"select" format**
+
+Example:
+ ``"must be a %select{unary|binary|unary or binary}2 operator"``
+Class:
+ Integers
+Description:
+ This format specifier is used to merge multiple related diagnostics together
+ into one common one, without requiring the difference to be specified as an
+ English string argument. Instead of specifying the string, the diagnostic
+ gets an integer argument and the format string selects the numbered option.
+ In this case, the "``%2``" value must be an integer in the range [0..2]. If
+ it is 0, it prints "unary", if it is 1 it prints "binary" if it is 2, it
+ prints "unary or binary". This allows other language translations to
+ substitute reasonable words (or entire phrases) based on the semantics of the
+ diagnostic instead of having to do things textually. The selected string
+ does undergo formatting.
+
+**"plural" format**
+
+Example:
+ ``"you have %1 %plural{1:mouse|:mice}1 connected to your computer"``
+Class:
+ Integers
+Description:
+ This is a formatter for complex plural forms. It is designed to handle even
+ the requirements of languages with very complex plural forms, as many Baltic
+ languages have. The argument consists of a series of expression/form pairs,
+ separated by ":", where the first form whose expression evaluates to true is
+ the result of the modifier.
+
+ An expression can be empty, in which case it is always true. See the example
+ at the top. Otherwise, it is a series of one or more numeric conditions,
+ separated by ",". If any condition matches, the expression matches. Each
+ numeric condition can take one of three forms.
+
+ * number: A simple decimal number matches if the argument is the same as the
+ number. Example: ``"%plural{1:mouse|:mice}4"``
+ * range: A range in square brackets matches if the argument is within the
+ range. Then range is inclusive on both ends. Example:
+ ``"%plural{0:none|1:one|[2,5]:some|:many}2"``
+ * modulo: A modulo operator is followed by a number, and equals sign and
+ either a number or a range. The tests are the same as for plain numbers
+ and ranges, but the argument is taken modulo the number first. Example:
+ ``"%plural{%100=0:even hundred|%100=[1,50]:lower half|:everything else}1"``
+
+ The parser is very unforgiving. A syntax error, even whitespace, will abort,
+ as will a failure to match the argument against any expression.
+
+**"ordinal" format**
+
+Example:
+ ``"ambiguity in %ordinal0 argument"``
+Class:
+ Integers
+Description:
+ This is a formatter which represents the argument number as an ordinal: the
+ value ``1`` becomes ``1st``, ``3`` becomes ``3rd``, and so on. Values less
+ than ``1`` are not supported. This formatter is currently hard-coded to use
+ English ordinals.
+
+**"objcclass" format**
+
+Example:
+ ``"method %objcclass0 not found"``
+Class:
+ ``DeclarationName``
+Description:
+ This is a simple formatter that indicates the ``DeclarationName`` corresponds
+ to an Objective-C class method selector. As such, it prints the selector
+ with a leading "``+``".
+
+**"objcinstance" format**
+
+Example:
+ ``"method %objcinstance0 not found"``
+Class:
+ ``DeclarationName``
+Description:
+ This is a simple formatter that indicates the ``DeclarationName`` corresponds
+ to an Objective-C instance method selector. As such, it prints the selector
+ with a leading "``-``".
+
+**"q" format**
+
+Example:
+ ``"candidate found by name lookup is %q0"``
+Class:
+ ``NamedDecl *``
+Description:
+ This formatter indicates that the fully-qualified name of the declaration
+ should be printed, e.g., "``std::vector``" rather than "``vector``".
+
+**"diff" format**
+
+Example:
+ ``"no known conversion %diff{from $ to $|from argument type to parameter type}1,2"``
+Class:
+ ``QualType``
+Description:
+ This formatter takes two ``QualType``\ s and attempts to print a template
+ difference between the two. If tree printing is off, the text inside the
+ braces before the pipe is printed, with the formatted text replacing the $.
+ If tree printing is on, the text after the pipe is printed and a type tree is
+ printed after the diagnostic message.
+
+It is really easy to add format specifiers to the Clang diagnostics system, but
+they should be discussed before they are added. If you are creating a lot of
+repetitive diagnostics and/or have an idea for a useful formatter, please bring
+it up on the cfe-dev mailing list.
+
+.. _internals-producing-diag:
+
+Producing the Diagnostic
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Now that you've created the diagnostic in the ``Diagnostic*Kinds.td`` file, you
+need to write the code that detects the condition in question and emits the new
+diagnostic. Various components of Clang (e.g., the preprocessor, ``Sema``,
+etc.) provide a helper function named "``Diag``". It creates a diagnostic and
+accepts the arguments, ranges, and other information that goes along with it.
+
+For example, the binary expression error comes from code like this:
+
+.. code-block:: c++
+
+ if (various things that are bad)
+ Diag(Loc, diag::err_typecheck_invalid_operands)
+ << lex->getType() << rex->getType()
+ << lex->getSourceRange() << rex->getSourceRange();
+
+This shows that use of the ``Diag`` method: it takes a location (a
+:ref:`SourceLocation <SourceLocation>` object) and a diagnostic enum value
+(which matches the name from ``Diagnostic*Kinds.td``). If the diagnostic takes
+arguments, they are specified with the ``<<`` operator: the first argument
+becomes ``%0``, the second becomes ``%1``, etc. The diagnostic interface
+allows you to specify arguments of many different types, including ``int`` and
+``unsigned`` for integer arguments, ``const char*`` and ``std::string`` for
+string arguments, ``DeclarationName`` and ``const IdentifierInfo *`` for names,
+``QualType`` for types, etc. ``SourceRange``\ s are also specified with the
+``<<`` operator, but do not have a specific ordering requirement.
+
+As you can see, adding and producing a diagnostic is pretty straightforward.
+The hard part is deciding exactly what you need to say to help the user,
+picking a suitable wording, and providing the information needed to format it
+correctly. The good news is that the call site that issues a diagnostic should
+be completely independent of how the diagnostic is formatted and in what
+language it is rendered.
+
+Fix-It Hints
+^^^^^^^^^^^^
+
+In some cases, the front end emits diagnostics when it is clear that some small
+change to the source code would fix the problem. For example, a missing
+semicolon at the end of a statement or a use of deprecated syntax that is
+easily rewritten into a more modern form. Clang tries very hard to emit the
+diagnostic and recover gracefully in these and other cases.
+
+However, for these cases where the fix is obvious, the diagnostic can be
+annotated with a hint (referred to as a "fix-it hint") that describes how to
+change the code referenced by the diagnostic to fix the problem. For example,
+it might add the missing semicolon at the end of the statement or rewrite the
+use of a deprecated construct into something more palatable. Here is one such
+example from the C++ front end, where we warn about the right-shift operator
+changing meaning from C++98 to C++11:
+
+.. code-block:: text
+
+ test.cpp:3:7: warning: use of right-shift operator ('>>') in template argument
+ will require parentheses in C++11
+ A<100 >> 2> *a;
+ ^
+ ( )
+
+Here, the fix-it hint is suggesting that parentheses be added, and showing
+exactly where those parentheses would be inserted into the source code. The
+fix-it hints themselves describe what changes to make to the source code in an
+abstract manner, which the text diagnostic printer renders as a line of
+"insertions" below the caret line. :ref:`Other diagnostic clients
+<DiagnosticClient>` might choose to render the code differently (e.g., as
+markup inline) or even give the user the ability to automatically fix the
+problem.
+
+Fix-it hints on errors and warnings need to obey these rules:
+
+* Since they are automatically applied if ``-Xclang -fixit`` is passed to the
+ driver, they should only be used when it's very likely they match the user's
+ intent.
+* Clang must recover from errors as if the fix-it had been applied.
+
+If a fix-it can't obey these rules, put the fix-it on a note. Fix-its on notes
+are not applied automatically.
+
+All fix-it hints are described by the ``FixItHint`` class, instances of which
+should be attached to the diagnostic using the ``<<`` operator in the same way
+that highlighted source ranges and arguments are passed to the diagnostic.
+Fix-it hints can be created with one of three constructors:
+
+* ``FixItHint::CreateInsertion(Loc, Code)``
+
+ Specifies that the given ``Code`` (a string) should be inserted before the
+ source location ``Loc``.
+
+* ``FixItHint::CreateRemoval(Range)``
+
+ Specifies that the code in the given source ``Range`` should be removed.
+
+* ``FixItHint::CreateReplacement(Range, Code)``
+
+ Specifies that the code in the given source ``Range`` should be removed,
+ and replaced with the given ``Code`` string.
+
+.. _DiagnosticClient:
+
+The ``DiagnosticClient`` Interface
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once code generates a diagnostic with all of the arguments and the rest of the
+relevant information, Clang needs to know what to do with it. As previously
+mentioned, the diagnostic machinery goes through some filtering to map a
+severity onto a diagnostic level, then (assuming the diagnostic is not mapped
+to "``Ignore``") it invokes an object that implements the ``DiagnosticClient``
+interface with the information.
+
+It is possible to implement this interface in many different ways. For
+example, the normal Clang ``DiagnosticClient`` (named
+``TextDiagnosticPrinter``) turns the arguments into strings (according to the
+various formatting rules), prints out the file/line/column information and the
+string, then prints out the line of code, the source ranges, and the caret.
+However, this behavior isn't required.
+
+Another implementation of the ``DiagnosticClient`` interface is the
+``TextDiagnosticBuffer`` class, which is used when Clang is in ``-verify``
+mode. Instead of formatting and printing out the diagnostics, this
+implementation just captures and remembers the diagnostics as they fly by.
+Then ``-verify`` compares the list of produced diagnostics to the list of
+expected ones. If they disagree, it prints out its own output. Full
+documentation for the ``-verify`` mode can be found in the Clang API
+documentation for `VerifyDiagnosticConsumer
+</doxygen/classclang_1_1VerifyDiagnosticConsumer.html#details>`_.
+
+There are many other possible implementations of this interface, and this is
+why we prefer diagnostics to pass down rich structured information in
+arguments. For example, an HTML output might want declaration names be
+linkified to where they come from in the source. Another example is that a GUI
+might let you click on typedefs to expand them. This application would want to
+pass significantly more information about types through to the GUI than a
+simple flat string. The interface allows this to happen.
+
+.. _internals-diag-translation:
+
+Adding Translations to Clang
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Not possible yet! Diagnostic strings should be written in UTF-8, the client can
+translate to the relevant code page if needed. Each translation completely
+replaces the format string for the diagnostic.
+
+.. _SourceLocation:
+.. _SourceManager:
+
+The ``SourceLocation`` and ``SourceManager`` classes
+----------------------------------------------------
+
+Strangely enough, the ``SourceLocation`` class represents a location within the
+source code of the program. Important design points include:
+
+#. ``sizeof(SourceLocation)`` must be extremely small, as these are embedded
+ into many AST nodes and are passed around often. Currently it is 32 bits.
+#. ``SourceLocation`` must be a simple value object that can be efficiently
+ copied.
+#. We should be able to represent a source location for any byte of any input
+ file. This includes in the middle of tokens, in whitespace, in trigraphs,
+ etc.
+#. A ``SourceLocation`` must encode the current ``#include`` stack that was
+ active when the location was processed. For example, if the location
+ corresponds to a token, it should contain the set of ``#include``\ s active
+ when the token was lexed. This allows us to print the ``#include`` stack
+ for a diagnostic.
+#. ``SourceLocation`` must be able to describe macro expansions, capturing both
+ the ultimate instantiation point and the source of the original character
+ data.
+
+In practice, the ``SourceLocation`` works together with the ``SourceManager``
+class to encode two pieces of information about a location: its spelling
+location and its instantiation location. For most tokens, these will be the
+same. However, for a macro expansion (or tokens that came from a ``_Pragma``
+directive) these will describe the location of the characters corresponding to
+the token and the location where the token was used (i.e., the macro
+instantiation point or the location of the ``_Pragma`` itself).
+
+The Clang front-end inherently depends on the location of a token being tracked
+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
+
+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;
+ ^first ^last
+
+To map from this representation to a character-based representation, the "last"
+location needs to be adjusted to point to (or past) the end of that token with
+either ``Lexer::MeasureTokenLength()`` or ``Lexer::getLocForEndOfToken()``. For
+the rare cases where character-level source ranges information is needed we use
+the ``CharSourceRange`` class.
+
+The Driver Library
+==================
+
+The clang Driver and library are documented :doc:`here <DriverInternals>`.
+
+Precompiled Headers
+===================
+
+Clang supports two implementations of precompiled headers. The default
+implementation, precompiled headers (:doc:`PCH <PCHInternals>`) uses a
+serialized representation of Clang's internal data structures, encoded with the
+`LLVM bitstream format <http://llvm.org/docs/BitCodeFormat.html>`_.
+Pretokenized headers (:doc:`PTH <PTHInternals>`), on the other hand, contain a
+serialized representation of the tokens encountered when preprocessing a header
+(and anything that header includes).
+
+The Frontend Library
+====================
+
+The Frontend library contains functionality useful for building tools on top of
+the Clang libraries, for example several methods for outputting diagnostics.
+
+The Lexer and Preprocessor Library
+==================================
+
+The Lexer library contains several tightly-connected classes that are involved
+with the nasty process of lexing and preprocessing C source code. The main
+interface to this library for outside clients is the large ``Preprocessor``
+class. It contains the various pieces of state that are required to coherently
+read tokens out of a translation unit.
+
+The core interface to the ``Preprocessor`` object (once it is set up) is the
+``Preprocessor::Lex`` method, which returns the next :ref:`Token <Token>` from
+the preprocessor stream. There are two types of token providers that the
+preprocessor is capable of reading from: a buffer lexer (provided by the
+:ref:`Lexer <Lexer>` class) and a buffered token stream (provided by the
+:ref:`TokenLexer <TokenLexer>` class).
+
+.. _Token:
+
+The Token class
+---------------
+
+The ``Token`` class is used to represent a single lexed token. Tokens are
+intended to be used by the lexer/preprocess and parser libraries, but are not
+intended to live beyond them (for example, they should not live in the ASTs).
+
+Tokens most often live on the stack (or some other location that is efficient
+to access) as the parser is running, but occasionally do get buffered up. For
+example, macro definitions are stored as a series of tokens, and the C++
+front-end periodically needs to buffer tokens up for tentative parsing and
+various pieces of look-ahead. As such, the size of a ``Token`` matters. On a
+32-bit system, ``sizeof(Token)`` is currently 16 bytes.
+
+Tokens occur in two forms: :ref:`annotation tokens <AnnotationToken>` and
+normal tokens. Normal tokens are those returned by the lexer, annotation
+tokens represent semantic information and are produced by the parser, replacing
+normal tokens in the token stream. Normal tokens contain the following
+information:
+
+* **A SourceLocation** --- This indicates the location of the start of the
+ token.
+
+* **A length** --- This stores the length of the token as stored in the
+ ``SourceBuffer``. For tokens that include them, this length includes
+ trigraphs and escaped newlines which are ignored by later phases of the
+ compiler. By pointing into the original source buffer, it is always possible
+ to get the original spelling of a token completely accurately.
+
+* **IdentifierInfo** --- If a token takes the form of an identifier, and if
+ identifier lookup was enabled when the token was lexed (e.g., the lexer was
+ not reading in "raw" mode) this contains a pointer to the unique hash value
+ for the identifier. Because the lookup happens before keyword
+ identification, this field is set even for language keywords like "``for``".
+
+* **TokenKind** --- This indicates the kind of token as classified by the
+ lexer. This includes things like ``tok::starequal`` (for the "``*=``"
+ operator), ``tok::ampamp`` for the "``&&``" token, and keyword values (e.g.,
+ ``tok::kw_for``) for identifiers that correspond to keywords. Note that
+ some tokens can be spelled multiple ways. For example, C++ supports
+ "operator keywords", where things like "``and``" are treated exactly like the
+ "``&&``" operator. In these cases, the kind value is set to ``tok::ampamp``,
+ which is good for the parser, which doesn't have to consider both forms. For
+ something that cares about which form is used (e.g., the preprocessor
+ "stringize" operator) the spelling indicates the original form.
+
+* **Flags** --- There are currently four flags tracked by the
+ lexer/preprocessor system on a per-token basis:
+
+ #. **StartOfLine** --- This was the first token that occurred on its input
+ source line.
+ #. **LeadingSpace** --- There was a space character either immediately before
+ the token or transitively before the token as it was expanded through a
+ macro. The definition of this flag is very closely defined by the
+ stringizing requirements of the preprocessor.
+ #. **DisableExpand** --- This flag is used internally to the preprocessor to
+ represent identifier tokens which have macro expansion disabled. This
+ prevents them from being considered as candidates for macro expansion ever
+ in the future.
+ #. **NeedsCleaning** --- This flag is set if the original spelling for the
+ token includes a trigraph or escaped newline. Since this is uncommon,
+ many pieces of code can fast-path on tokens that did not need cleaning.
+
+One interesting (and somewhat unusual) aspect of normal tokens is that they
+don't contain any semantic information about the lexed value. For example, if
+the token was a pp-number token, we do not represent the value of the number
+that was lexed (this is left for later pieces of code to decide).
+Additionally, the lexer library has no notion of typedef names vs variable
+names: both are returned as identifiers, and the parser is left to decide
+whether a specific identifier is a typedef or a variable (tracking this
+requires scope information among other things). The parser can do this
+translation by replacing tokens returned by the preprocessor with "Annotation
+Tokens".
+
+.. _AnnotationToken:
+
+Annotation Tokens
+-----------------
+
+Annotation tokens are tokens that are synthesized by the parser and injected
+into the preprocessor's token stream (replacing existing tokens) to record
+semantic information found by the parser. For example, if "``foo``" is found
+to be a typedef, the "``foo``" ``tok::identifier`` token is replaced with an
+``tok::annot_typename``. This is useful for a couple of reasons: 1) this makes
+it easy to handle qualified type names (e.g., "``foo::bar::baz<42>::t``") in
+C++ as a single "token" in the parser. 2) if the parser backtracks, the
+reparse does not need to redo semantic analysis to determine whether a token
+sequence is a variable, type, template, etc.
+
+Annotation tokens are created by the parser and reinjected into the parser's
+token stream (when backtracking is enabled). Because they can only exist in
+tokens that the preprocessor-proper is done with, it doesn't need to keep
+around flags like "start of line" that the preprocessor uses to do its job.
+Additionally, an annotation token may "cover" a sequence of preprocessor tokens
+(e.g., "``a::b::c``" is five preprocessor tokens). As such, the valid fields
+of an annotation token are different than the fields for a normal token (but
+they are multiplexed into the normal ``Token`` fields):
+
+* **SourceLocation "Location"** --- The ``SourceLocation`` for the annotation
+ token indicates the first token replaced by the annotation token. In the
+ example above, it would be the location of the "``a``" identifier.
+* **SourceLocation "AnnotationEndLoc"** --- This holds the location of the last
+ token replaced with the annotation token. In the example above, it would be
+ the location of the "``c``" identifier.
+* **void* "AnnotationValue"** --- This contains an opaque object that the
+ parser gets from ``Sema``. The parser merely preserves the information for
+ ``Sema`` to later interpret based on the annotation token kind.
+* **TokenKind "Kind"** --- This indicates the kind of Annotation token this is.
+ See below for the different valid kinds.
+
+Annotation tokens currently come in three kinds:
+
+#. **tok::annot_typename**: This annotation token represents a resolved
+ typename token that is potentially qualified. The ``AnnotationValue`` field
+ contains the ``QualType`` returned by ``Sema::getTypeName()``, possibly with
+ source location information attached.
+#. **tok::annot_cxxscope**: This annotation token represents a C++ scope
+ specifier, such as "``A::B::``". This corresponds to the grammar
+ productions "*::*" and "*:: [opt] nested-name-specifier*". The
+ ``AnnotationValue`` pointer is a ``NestedNameSpecifier *`` returned by the
+ ``Sema::ActOnCXXGlobalScopeSpecifier`` and
+ ``Sema::ActOnCXXNestedNameSpecifier`` callbacks.
+#. **tok::annot_template_id**: This annotation token represents a C++
+ template-id such as "``foo<int, 4>``", where "``foo``" is the name of a
+ template. The ``AnnotationValue`` pointer is a pointer to a ``malloc``'d
+ ``TemplateIdAnnotation`` object. Depending on the context, a parsed
+ template-id that names a type might become a typename annotation token (if
+ all we care about is the named type, e.g., because it occurs in a type
+ specifier) or might remain a template-id token (if we want to retain more
+ source location information or produce a new type, e.g., in a declaration of
+ a class template specialization). template-id annotation tokens that refer
+ to a type can be "upgraded" to typename annotation tokens by the parser.
+
+As mentioned above, annotation tokens are not returned by the preprocessor,
+they are formed on demand by the parser. This means that the parser has to be
+aware of cases where an annotation could occur and form it where appropriate.
+This is somewhat similar to how the parser handles Translation Phase 6 of C99:
+String Concatenation (see C99 5.1.1.2). In the case of string concatenation,
+the preprocessor just returns distinct ``tok::string_literal`` and
+``tok::wide_string_literal`` tokens and the parser eats a sequence of them
+wherever the grammar indicates that a string literal can occur.
+
+In order to do this, whenever the parser expects a ``tok::identifier`` or
+``tok::coloncolon``, it should call the ``TryAnnotateTypeOrScopeToken`` or
+``TryAnnotateCXXScopeToken`` methods to form the annotation token. These
+methods will maximally form the specified annotation tokens and replace the
+current token with them, if applicable. If the current tokens is not valid for
+an annotation token, it will remain an identifier or "``::``" token.
+
+.. _Lexer:
+
+The ``Lexer`` class
+-------------------
+
+The ``Lexer`` class provides the mechanics of lexing tokens out of a source
+buffer and deciding what they mean. The ``Lexer`` is complicated by the fact
+that it operates on raw buffers that have not had spelling eliminated (this is
+a necessity to get decent performance), but this is countered with careful
+coding as well as standard performance techniques (for example, the comment
+handling code is vectorized on X86 and PowerPC hosts).
+
+The lexer has a couple of interesting modal features:
+
+* The lexer can operate in "raw" mode. This mode has several features that
+ make it possible to quickly lex the file (e.g., it stops identifier lookup,
+ doesn't specially handle preprocessor tokens, handles EOF differently, etc).
+ This mode is used for lexing within an "``#if 0``" block, for example.
+* The lexer can capture and return comments as tokens. This is required to
+ support the ``-C`` preprocessor mode, which passes comments through, and is
+ used by the diagnostic checker to identifier expect-error annotations.
+* The lexer can be in ``ParsingFilename`` mode, which happens when
+ preprocessing after reading a ``#include`` directive. This mode changes the
+ parsing of "``<``" to return an "angled string" instead of a bunch of tokens
+ for each thing within the filename.
+* When parsing a preprocessor directive (after "``#``") the
+ ``ParsingPreprocessorDirective`` mode is entered. This changes the parser to
+ return EOD at a newline.
+* The ``Lexer`` uses a ``LangOptions`` object to know whether trigraphs are
+ enabled, whether C++ or ObjC keywords are recognized, etc.
+
+In addition to these modes, the lexer keeps track of a couple of other features
+that are local to a lexed buffer, which change as the buffer is lexed:
+
+* The ``Lexer`` uses ``BufferPtr`` to keep track of the current character being
+ lexed.
+* The ``Lexer`` uses ``IsAtStartOfLine`` to keep track of whether the next
+ lexed token will start with its "start of line" bit set.
+* The ``Lexer`` keeps track of the current "``#if``" directives that are active
+ (which can be nested).
+* The ``Lexer`` keeps track of an :ref:`MultipleIncludeOpt
+ <MultipleIncludeOpt>` object, which is used to detect whether the buffer uses
+ the standard "``#ifndef XX`` / ``#define XX``" idiom to prevent multiple
+ inclusion. If a buffer does, subsequent includes can be ignored if the
+ "``XX``" macro is defined.
+
+.. _TokenLexer:
+
+The ``TokenLexer`` class
+------------------------
+
+The ``TokenLexer`` class is a token provider that returns tokens from a list of
+tokens that came from somewhere else. It typically used for two things: 1)
+returning tokens from a macro definition as it is being expanded 2) returning
+tokens from an arbitrary buffer of tokens. The later use is used by
+``_Pragma`` and will most likely be used to handle unbounded look-ahead for the
+C++ parser.
+
+.. _MultipleIncludeOpt:
+
+The ``MultipleIncludeOpt`` class
+--------------------------------
+
+The ``MultipleIncludeOpt`` class implements a really simple little state
+machine that is used to detect the standard "``#ifndef XX`` / ``#define XX``"
+idiom that people typically use to prevent multiple inclusion of headers. If a
+buffer uses this idiom and is subsequently ``#include``'d, the preprocessor can
+simply check to see whether the guarding condition is defined or not. If so,
+the preprocessor can completely ignore the include of the header.
+
+.. _Parser:
+
+The Parser Library
+==================
+
+This library contains a recursive-descent parser that polls tokens from the
+preprocessor and notifies a client of the parsing progress.
+
+Historically, the parser used to talk to an abstract ``Action`` interface that
+had virtual methods for parse events, for example ``ActOnBinOp()``. When Clang
+grew C++ support, the parser stopped supporting general ``Action`` clients --
+it now always talks to the :ref:`Sema libray <Sema>`. However, the Parser
+still accesses AST objects only through opaque types like ``ExprResult`` and
+``StmtResult``. Only :ref:`Sema <Sema>` looks at the AST node contents of these
+wrappers.
+
+.. _AST:
+
+The AST Library
+===============
+
+.. _Type:
+
+The ``Type`` class and its subclasses
+-------------------------------------
+
+The ``Type`` class (and its subclasses) are an important part of the AST.
+Types are accessed through the ``ASTContext`` class, which implicitly creates
+and uniques them as they are needed. Types have a couple of non-obvious
+features: 1) they do not capture type qualifiers like ``const`` or ``volatile``
+(see :ref:`QualType <QualType>`), and 2) they implicitly capture typedef
+information. Once created, types are immutable (unlike decls).
+
+Typedefs in C make semantic analysis a bit more complex than it would be without
+them. The issue is that we want to capture typedef information and represent it
+in the AST perfectly, but the semantics of operations need to "see through"
+typedefs. For example, consider this code:
+
+.. code-block:: c++
+
+ void func() {
+ typedef int foo;
+ foo X, *Y;
+ typedef foo *bar;
+ bar Z;
+ *X; // error
+ **Y; // error
+ **Z; // error
+ }
+
+The code above is illegal, and thus we expect there to be diagnostics emitted
+on the annotated lines. In this example, we expect to get:
+
+.. code-block:: text
+
+ test.c:6:1: error: indirection requires pointer operand ('foo' invalid)
+ *X; // error
+ ^~
+ test.c:7:1: error: indirection requires pointer operand ('foo' invalid)
+ **Y; // error
+ ^~~
+ test.c:8:1: error: indirection requires pointer operand ('foo' invalid)
+ **Z; // error
+ ^~~
+
+While this example is somewhat silly, it illustrates the point: we want to
+retain typedef information where possible, so that we can emit errors about
+"``std::string``" instead of "``std::basic_string<char, std:...``". Doing this
+requires properly keeping typedef information (for example, the type of ``X``
+is "``foo``", not "``int``"), and requires properly propagating it through the
+various operators (for example, the type of ``*Y`` is "``foo``", not
+"``int``"). In order to retain this information, the type of these expressions
+is an instance of the ``TypedefType`` class, which indicates that the type of
+these expressions is a typedef for "``foo``".
+
+Representing types like this is great for diagnostics, because the
+user-specified type is always immediately available. There are two problems
+with this: first, various semantic checks need to make judgements about the
+*actual structure* of a type, ignoring typedefs. Second, we need an efficient
+way to query whether two types are structurally identical to each other,
+ignoring typedefs. The solution to both of these problems is the idea of
+canonical types.
+
+Canonical Types
+^^^^^^^^^^^^^^^
+
+Every instance of the ``Type`` class contains a canonical type pointer. For
+simple types with no typedefs involved (e.g., "``int``", "``int*``",
+"``int**``"), the type just points to itself. For types that have a typedef
+somewhere in their structure (e.g., "``foo``", "``foo*``", "``foo**``",
+"``bar``"), the canonical type pointer points to their structurally equivalent
+type without any typedefs (e.g., "``int``", "``int*``", "``int**``", and
+"``int*``" respectively).
+
+This design provides a constant time operation (dereferencing the canonical type
+pointer) that gives us access to the structure of types. For example, we can
+trivially tell that "``bar``" and "``foo*``" are the same type by dereferencing
+their canonical type pointers and doing a pointer comparison (they both point
+to the single "``int*``" type).
+
+Canonical types and typedef types bring up some complexities that must be
+carefully managed. Specifically, the ``isa``/``cast``/``dyn_cast`` operators
+generally shouldn't be used in code that is inspecting the AST. For example,
+when type checking the indirection operator (unary "``*``" on a pointer), the
+type checker must verify that the operand has a pointer type. It would not be
+correct to check that with "``isa<PointerType>(SubExpr->getType())``", because
+this predicate would fail if the subexpression had a typedef type.
+
+The solution to this problem are a set of helper methods on ``Type``, used to
+check their properties. In this case, it would be correct to use
+"``SubExpr->getType()->isPointerType()``" to do the check. This predicate will
+return true if the *canonical type is a pointer*, which is true any time the
+type is structurally a pointer type. The only hard part here is remembering
+not to use the ``isa``/``cast``/``dyn_cast`` operations.
+
+The second problem we face is how to get access to the pointer type once we
+know it exists. To continue the example, the result type of the indirection
+operator is the pointee type of the subexpression. In order to determine the
+type, we need to get the instance of ``PointerType`` that best captures the
+typedef information in the program. If the type of the expression is literally
+a ``PointerType``, we can return that, otherwise we have to dig through the
+typedefs to find the pointer type. For example, if the subexpression had type
+"``foo*``", we could return that type as the result. If the subexpression had
+type "``bar``", we want to return "``foo*``" (note that we do *not* want
+"``int*``"). In order to provide all of this, ``Type`` has a
+``getAsPointerType()`` method that checks whether the type is structurally a
+``PointerType`` and, if so, returns the best one. If not, it returns a null
+pointer.
+
+This structure is somewhat mystical, but after meditating on it, it will make
+sense to you :).
+
+.. _QualType:
+
+The ``QualType`` class
+----------------------
+
+The ``QualType`` class is designed as a trivial value class that is small,
+passed by-value and is efficient to query. The idea of ``QualType`` is that it
+stores the type qualifiers (``const``, ``volatile``, ``restrict``, plus some
+extended qualifiers required by language extensions) separately from the types
+themselves. ``QualType`` is conceptually a pair of "``Type*``" and the bits
+for these type qualifiers.
+
+By storing the type qualifiers as bits in the conceptual pair, it is extremely
+efficient to get the set of qualifiers on a ``QualType`` (just return the field
+of the pair), add a type qualifier (which is a trivial constant-time operation
+that sets a bit), and remove one or more type qualifiers (just return a
+``QualType`` with the bitfield set to empty).
+
+Further, because the bits are stored outside of the type itself, we do not need
+to create duplicates of types with different sets of qualifiers (i.e. there is
+only a single heap allocated "``int``" type: "``const int``" and "``volatile
+const int``" both point to the same heap allocated "``int``" type). This
+reduces the heap size used to represent bits and also means we do not have to
+consider qualifiers when uniquing types (:ref:`Type <Type>` does not even
+contain qualifiers).
+
+In practice, the two most common type qualifiers (``const`` and ``restrict``)
+are stored in the low bits of the pointer to the ``Type`` object, together with
+a flag indicating whether extended qualifiers are present (which must be
+heap-allocated). This means that ``QualType`` is exactly the same size as a
+pointer.
+
+.. _DeclarationName:
+
+Declaration names
+-----------------
+
+The ``DeclarationName`` class represents the name of a declaration in Clang.
+Declarations in the C family of languages can take several different forms.
+Most declarations are named by simple identifiers, e.g., "``f``" and "``x``" in
+the function declaration ``f(int x)``. In C++, declaration names can also name
+class constructors ("``Class``" in ``struct Class { Class(); }``), class
+destructors ("``~Class``"), overloaded operator names ("``operator+``"), and
+conversion functions ("``operator void const *``"). In Objective-C,
+declaration names can refer to the names of Objective-C methods, which involve
+the method name and the parameters, collectively called a *selector*, e.g.,
+"``setWidth:height:``". Since all of these kinds of entities --- variables,
+functions, Objective-C methods, C++ constructors, destructors, and operators
+--- are represented as subclasses of Clang's common ``NamedDecl`` class,
+``DeclarationName`` is designed to efficiently represent any kind of name.
+
+Given a ``DeclarationName`` ``N``, ``N.getNameKind()`` will produce a value
+that describes what kind of name ``N`` stores. There are 10 options (all of
+the names are inside the ``DeclarationName`` class).
+
+``Identifier``
+
+ The name is a simple identifier. Use ``N.getAsIdentifierInfo()`` to retrieve
+ the corresponding ``IdentifierInfo*`` pointing to the actual identifier.
+
+``ObjCZeroArgSelector``, ``ObjCOneArgSelector``, ``ObjCMultiArgSelector``
+
+ The name is an Objective-C selector, which can be retrieved as a ``Selector``
+ instance via ``N.getObjCSelector()``. The three possible name kinds for
+ Objective-C reflect an optimization within the ``DeclarationName`` class:
+ both zero- and one-argument selectors are stored as a masked
+ ``IdentifierInfo`` pointer, and therefore require very little space, since
+ zero- and one-argument selectors are far more common than multi-argument
+ selectors (which use a different structure).
+
+``CXXConstructorName``
+
+ The name is a C++ constructor name. Use ``N.getCXXNameType()`` to retrieve
+ the :ref:`type <QualType>` that this constructor is meant to construct. The
+ type is always the canonical type, since all constructors for a given type
+ have the same name.
+
+``CXXDestructorName``
+
+ The name is a C++ destructor name. Use ``N.getCXXNameType()`` to retrieve
+ the :ref:`type <QualType>` whose destructor is being named. This type is
+ always a canonical type.
+
+``CXXConversionFunctionName``
+
+ The name is a C++ conversion function. Conversion functions are named
+ according to the type they convert to, e.g., "``operator void const *``".
+ Use ``N.getCXXNameType()`` to retrieve the type that this conversion function
+ converts to. This type is always a canonical type.
+
+``CXXOperatorName``
+
+ The name is a C++ overloaded operator name. Overloaded operators are named
+ according to their spelling, e.g., "``operator+``" or "``operator new []``".
+ Use ``N.getCXXOverloadedOperator()`` to retrieve the overloaded operator (a
+ value of type ``OverloadedOperatorKind``).
+
+``CXXLiteralOperatorName``
+
+ The name is a C++11 user defined literal operator. User defined
+ Literal operators are named according to the suffix they define,
+ e.g., "``_foo``" for "``operator "" _foo``". Use
+ ``N.getCXXLiteralIdentifier()`` to retrieve the corresponding
+ ``IdentifierInfo*`` pointing to the identifier.
+
+``CXXUsingDirective``
+
+ The name is a C++ using directive. Using directives are not really
+ NamedDecls, in that they all have the same name, but they are
+ implemented as such in order to store them in DeclContext
+ effectively.
+
+``DeclarationName``\ s are cheap to create, copy, and compare. They require
+only a single pointer's worth of storage in the common cases (identifiers,
+zero- and one-argument Objective-C selectors) and use dense, uniqued storage
+for the other kinds of names. Two ``DeclarationName``\ s can be compared for
+equality (``==``, ``!=``) using a simple bitwise comparison, can be ordered
+with ``<``, ``>``, ``<=``, and ``>=`` (which provide a lexicographical ordering
+for normal identifiers but an unspecified ordering for other kinds of names),
+and can be placed into LLVM ``DenseMap``\ s and ``DenseSet``\ s.
+
+``DeclarationName`` instances can be created in different ways depending on
+what kind of name the instance will store. Normal identifiers
+(``IdentifierInfo`` pointers) and Objective-C selectors (``Selector``) can be
+implicitly converted to ``DeclarationNames``. Names for C++ constructors,
+destructors, conversion functions, and overloaded operators can be retrieved
+from the ``DeclarationNameTable``, an instance of which is available as
+``ASTContext::DeclarationNames``. The member functions
+``getCXXConstructorName``, ``getCXXDestructorName``,
+``getCXXConversionFunctionName``, and ``getCXXOperatorName``, respectively,
+return ``DeclarationName`` instances for the four kinds of C++ special function
+names.
+
+.. _DeclContext:
+
+Declaration contexts
+--------------------
+
+Every declaration in a program exists within some *declaration context*, such
+as a translation unit, namespace, class, or function. Declaration contexts in
+Clang are represented by the ``DeclContext`` class, from which the various
+declaration-context AST nodes (``TranslationUnitDecl``, ``NamespaceDecl``,
+``RecordDecl``, ``FunctionDecl``, etc.) will derive. The ``DeclContext`` class
+provides several facilities common to each declaration context:
+
+Source-centric vs. Semantics-centric View of Declarations
+
+ ``DeclContext`` provides two views of the declarations stored within a
+ declaration context. The source-centric view accurately represents the
+ program source code as written, including multiple declarations of entities
+ where present (see the section :ref:`Redeclarations and Overloads
+ <Redeclarations>`), while the semantics-centric view represents the program
+ semantics. The two views are kept synchronized by semantic analysis while
+ the ASTs are being constructed.
+
+Storage of declarations within that context
+
+ Every declaration context can contain some number of declarations. For
+ example, a C++ class (represented by ``RecordDecl``) contains various member
+ functions, fields, nested types, and so on. All of these declarations will
+ be stored within the ``DeclContext``, and one can iterate over the
+ declarations via [``DeclContext::decls_begin()``,
+ ``DeclContext::decls_end()``). This mechanism provides the source-centric
+ view of declarations in the context.
+
+Lookup of declarations within that context
+
+ The ``DeclContext`` structure provides efficient name lookup for names within
+ that declaration context. For example, if ``N`` is a namespace we can look
+ for the name ``N::f`` using ``DeclContext::lookup``. The lookup itself is
+ based on a lazily-constructed array (for declaration contexts with a small
+ number of declarations) or hash table (for declaration contexts with more
+ declarations). The lookup operation provides the semantics-centric view of
+ the declarations in the context.
+
+Ownership of declarations
+
+ The ``DeclContext`` owns all of the declarations that were declared within
+ its declaration context, and is responsible for the management of their
+ memory as well as their (de-)serialization.
+
+All declarations are stored within a declaration context, and one can query
+information about the context in which each declaration lives. One can
+retrieve the ``DeclContext`` that contains a particular ``Decl`` using
+``Decl::getDeclContext``. However, see the section
+:ref:`LexicalAndSemanticContexts` for more information about how to interpret
+this context information.
+
+.. _Redeclarations:
+
+Redeclarations and Overloads
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Within a translation unit, it is common for an entity to be declared several
+times. For example, we might declare a function "``f``" and then later
+re-declare it as part of an inlined definition:
+
+.. code-block:: c++
+
+ void f(int x, int y, int z = 1);
+
+ inline void f(int x, int y, int z) { /* ... */ }
+
+The representation of "``f``" differs in the source-centric and
+semantics-centric views of a declaration context. In the source-centric view,
+all redeclarations will be present, in the order they occurred in the source
+code, making this view suitable for clients that wish to see the structure of
+the source code. In the semantics-centric view, only the most recent "``f``"
+will be found by the lookup, since it effectively replaces the first
+declaration of "``f``".
+
+In the semantics-centric view, overloading of functions is represented
+explicitly. For example, given two declarations of a function "``g``" that are
+overloaded, e.g.,
+
+.. code-block:: c++
+
+ void g();
+ void g(int);
+
+the ``DeclContext::lookup`` operation will return a
+``DeclContext::lookup_result`` that contains a range of iterators over
+declarations of "``g``". Clients that perform semantic analysis on a program
+that is not concerned with the actual source code will primarily use this
+semantics-centric view.
+
+.. _LexicalAndSemanticContexts:
+
+Lexical and Semantic Contexts
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Each declaration has two potentially different declaration contexts: a
+*lexical* context, which corresponds to the source-centric view of the
+declaration context, and a *semantic* context, which corresponds to the
+semantics-centric view. The lexical context is accessible via
+``Decl::getLexicalDeclContext`` while the semantic context is accessible via
+``Decl::getDeclContext``, both of which return ``DeclContext`` pointers. For
+most declarations, the two contexts are identical. For example:
+
+.. code-block:: c++
+
+ class X {
+ public:
+ void f(int x);
+ };
+
+Here, the semantic and lexical contexts of ``X::f`` are the ``DeclContext``
+associated with the class ``X`` (itself stored as a ``RecordDecl`` AST node).
+However, we can now define ``X::f`` out-of-line:
+
+.. code-block:: c++
+
+ void X::f(int x = 17) { /* ... */ }
+
+This definition of "``f``" has different lexical and semantic contexts. The
+lexical context corresponds to the declaration context in which the actual
+declaration occurred in the source code, e.g., the translation unit containing
+``X``. Thus, this declaration of ``X::f`` can be found by traversing the
+declarations provided by [``decls_begin()``, ``decls_end()``) in the
+translation unit.
+
+The semantic context of ``X::f`` corresponds to the class ``X``, since this
+member function is (semantically) a member of ``X``. Lookup of the name ``f``
+into the ``DeclContext`` associated with ``X`` will then return the definition
+of ``X::f`` (including information about the default argument).
+
+Transparent Declaration Contexts
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In C and C++, there are several contexts in which names that are logically
+declared inside another declaration will actually "leak" out into the enclosing
+scope from the perspective of name lookup. The most obvious instance of this
+behavior is in enumeration types, e.g.,
+
+.. code-block:: c++
+
+ enum Color {
+ Red,
+ Green,
+ Blue
+ };
+
+Here, ``Color`` is an enumeration, which is a declaration context that contains
+the enumerators ``Red``, ``Green``, and ``Blue``. Thus, traversing the list of
+declarations contained in the enumeration ``Color`` will yield ``Red``,
+``Green``, and ``Blue``. However, outside of the scope of ``Color`` one can
+name the enumerator ``Red`` without qualifying the name, e.g.,
+
+.. code-block:: c++
+
+ Color c = Red;
+
+There are other entities in C++ that provide similar behavior. For example,
+linkage specifications that use curly braces:
+
+.. code-block:: c++
+
+ extern "C" {
+ void f(int);
+ void g(int);
+ }
+ // f and g are visible here
+
+For source-level accuracy, we treat the linkage specification and enumeration
+type as a declaration context in which its enclosed declarations ("``Red``",
+"``Green``", and "``Blue``"; "``f``" and "``g``") are declared. However, these
+declarations are visible outside of the scope of the declaration context.
+
+These language features (and several others, described below) have roughly the
+same set of requirements: declarations are declared within a particular lexical
+context, but the declarations are also found via name lookup in scopes
+enclosing the declaration itself. This feature is implemented via
+*transparent* declaration contexts (see
+``DeclContext::isTransparentContext()``), whose declarations are visible in the
+nearest enclosing non-transparent declaration context. This means that the
+lexical context of the declaration (e.g., an enumerator) will be the
+transparent ``DeclContext`` itself, as will the semantic context, but the
+declaration will be visible in every outer context up to and including the
+first non-transparent declaration context (since transparent declaration
+contexts can be nested).
+
+The transparent ``DeclContext``\ s are:
+
+* Enumerations (but not C++11 "scoped enumerations"):
+
+ .. code-block:: c++
+
+ enum Color {
+ Red,
+ Green,
+ Blue
+ };
+ // Red, Green, and Blue are in scope
+
+* C++ linkage specifications:
+
+ .. code-block:: c++
+
+ extern "C" {
+ void f(int);
+ void g(int);
+ }
+ // f and g are in scope
+
+* Anonymous unions and structs:
+
+ .. code-block:: c++
+
+ struct LookupTable {
+ bool IsVector;
+ union {
+ std::vector<Item> *Vector;
+ std::set<Item> *Set;
+ };
+ };
+
+ LookupTable LT;
+ LT.Vector = 0; // Okay: finds Vector inside the unnamed union
+
+* C++11 inline namespaces:
+
+ .. code-block:: c++
+
+ namespace mylib {
+ inline namespace debug {
+ class X;
+ }
+ }
+ mylib::X *xp; // okay: mylib::X refers to mylib::debug::X
+
+.. _MultiDeclContext:
+
+Multiply-Defined Declaration Contexts
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+C++ namespaces have the interesting --- and, so far, unique --- property that
+the namespace can be defined multiple times, and the declarations provided by
+each namespace definition are effectively merged (from the semantic point of
+view). For example, the following two code snippets are semantically
+indistinguishable:
+
+.. code-block:: c++
+
+ // Snippet #1:
+ namespace N {
+ void f();
+ }
+ namespace N {
+ void f(int);
+ }
+
+ // Snippet #2:
+ namespace N {
+ void f();
+ void f(int);
+ }
+
+In Clang's representation, the source-centric view of declaration contexts will
+actually have two separate ``NamespaceDecl`` nodes in Snippet #1, each of which
+is a declaration context that contains a single declaration of "``f``".
+However, the semantics-centric view provided by name lookup into the namespace
+``N`` for "``f``" will return a ``DeclContext::lookup_result`` that contains a
+range of iterators over declarations of "``f``".
+
+``DeclContext`` manages multiply-defined declaration contexts internally. The
+function ``DeclContext::getPrimaryContext`` retrieves the "primary" context for
+a given ``DeclContext`` instance, which is the ``DeclContext`` responsible for
+maintaining the lookup table used for the semantics-centric view. Given a
+DeclContext, one can obtain the set of declaration contexts that are semanticaly
+connected to this declaration context, in source order, including this context
+(which will be the only result, for non-namespace contexts) via
+``DeclContext::collectAllContexts``. Note that these functions are used
+internally within the lookup and insertion methods of the ``DeclContext``, so
+the vast majority of clients can ignore them.
+
+.. _CFG:
+
+The ``CFG`` class
+-----------------
+
+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
+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
+statements within a block indicates unconditional flow of control from one
+statement to the next. :ref:`Conditional control-flow
+<ConditionalControlFlow>` is represented using edges between basic blocks. The
+statements within a given ``CFGBlock`` can be traversed using the
+``CFGBlock::*iterator`` interface.
+
+A ``CFG`` object owns the instances of ``CFGBlock`` within the control-flow
+graph it represents. Each ``CFGBlock`` within a CFG is also uniquely numbered
+(accessible via ``CFGBlock::getBlockID()``). Currently the number is based on
+the ordering the blocks were created, but no assumptions should be made on how
+``CFGBlocks`` are numbered other than their numbers are unique and that they
+are numbered from 0..N-1 (where N is the number of basic blocks in the CFG).
+
+Entry and Exit Blocks
+^^^^^^^^^^^^^^^^^^^^^
+
+Each instance of ``CFG`` contains two special blocks: an *entry* block
+(accessible via ``CFG::getEntry()``), which has no incoming edges, and an
+*exit* block (accessible via ``CFG::getExit()``), which has no outgoing edges.
+Neither block contains any statements, and they serve the role of providing a
+clear entrance and exit for a body of code such as a function body. The
+presence of these empty blocks greatly simplifies the implementation of many
+analyses built on top of CFGs.
+
+.. _ConditionalControlFlow:
+
+Conditional Control-Flow
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Conditional control-flow (such as those induced by if-statements and loops) is
+represented as edges between ``CFGBlocks``. Because different C language
+constructs can induce control-flow, each ``CFGBlock`` also records an extra
+``Stmt*`` that represents the *terminator* of the block. A terminator is
+simply the statement that caused the control-flow, and is used to identify the
+nature of the conditional control-flow between blocks. For example, in the
+case of an if-statement, the terminator refers to the ``IfStmt`` object in the
+AST that represented the given branch.
+
+To illustrate, consider the following code example:
+
+.. code-block:: c++
+
+ int foo(int x) {
+ x = x + 1;
+ if (x > 2)
+ x++;
+ else {
+ x += 2;
+ x *= 2;
+ }
+
+ return x;
+ }
+
+After invoking the parser+semantic analyzer on this code fragment, the AST of
+the body of ``foo`` is referenced by a single ``Stmt*``. We can then construct
+an instance of ``CFG`` representing the control-flow graph of this function
+body by single call to a static class method:
+
+.. code-block:: c++
+
+ Stmt *FooBody = ...
+ std::unique_ptr<CFG> FooCFG = CFG::buildCFG(FooBody);
+
+Along with providing an interface to iterate over its ``CFGBlocks``, the
+``CFG`` class also provides methods that are useful for debugging and
+visualizing CFGs. For example, the method ``CFG::dump()`` dumps a
+pretty-printed version of the CFG to standard error. This is especially useful
+when one is using a debugger such as gdb. For example, here is the output of
+``FooCFG->dump()``:
+
+.. code-block:: text
+
+ [ B5 (ENTRY) ]
+ Predecessors (0):
+ Successors (1): B4
+
+ [ B4 ]
+ 1: x = x + 1
+ 2: (x > 2)
+ T: if [B4.2]
+ Predecessors (1): B5
+ Successors (2): B3 B2
+
+ [ B3 ]
+ 1: x++
+ Predecessors (1): B4
+ Successors (1): B1
+
+ [ B2 ]
+ 1: x += 2
+ 2: x *= 2
+ Predecessors (1): B4
+ Successors (1): B1
+
+ [ B1 ]
+ 1: return x;
+ Predecessors (2): B2 B3
+ Successors (1): B0
+
+ [ B0 (EXIT) ]
+ Predecessors (1): B1
+ Successors (0):
+
+For each block, the pretty-printed output displays for each block the number of
+*predecessor* blocks (blocks that have outgoing control-flow to the given
+block) and *successor* blocks (blocks that have control-flow that have incoming
+control-flow from the given block). We can also clearly see the special entry
+and exit blocks at the beginning and end of the pretty-printed output. For the
+entry block (block B5), the number of predecessor blocks is 0, while for the
+exit block (block B0) the number of successor blocks is 0.
+
+The most interesting block here is B4, whose outgoing control-flow represents
+the branching caused by the sole if-statement in ``foo``. Of particular
+interest is the second statement in the block, ``(x > 2)``, and the terminator,
+printed as ``if [B4.2]``. The second statement represents the evaluation of
+the condition of the if-statement, which occurs before the actual branching of
+control-flow. Within the ``CFGBlock`` for B4, the ``Stmt*`` for the second
+statement refers to the actual expression in the AST for ``(x > 2)``. Thus
+pointers to subclasses of ``Expr`` can appear in the list of statements in a
+block, and not just subclasses of ``Stmt`` that refer to proper C statements.
+
+The terminator of block B4 is a pointer to the ``IfStmt`` object in the AST.
+The pretty-printer outputs ``if [B4.2]`` because the condition expression of
+the if-statement has an actual place in the basic block, and thus the
+terminator is essentially *referring* to the expression that is the second
+statement of block B4 (i.e., B4.2). In this manner, conditions for
+control-flow (which also includes conditions for loops and switch statements)
+are hoisted into the actual basic block.
+
+.. Implicit Control-Flow
+.. ^^^^^^^^^^^^^^^^^^^^^
+
+.. A key design principle of the ``CFG`` class was to not require any
+.. transformations to the AST in order to represent control-flow. Thus the
+.. ``CFG`` does not perform any "lowering" of the statements in an AST: loops
+.. are not transformed into guarded gotos, short-circuit operations are not
+.. converted to a set of if-statements, and so on.
+
+Constant Folding in the Clang AST
+---------------------------------
+
+There are several places where constants and constant folding matter a lot to
+the Clang front-end. First, in general, we prefer the AST to retain the source
+code as close to how the user wrote it as possible. This means that if they
+wrote "``5+4``", we want to keep the addition and two constants in the AST, we
+don't want to fold to "``9``". This means that constant folding in various
+ways turns into a tree walk that needs to handle the various cases.
+
+However, there are places in both C and C++ that require constants to be
+folded. For example, the C standard defines what an "integer constant
+expression" (i-c-e) is with very precise and specific requirements. The
+language then requires i-c-e's in a lot of places (for example, the size of a
+bitfield, the value for a case statement, etc). For these, we have to be able
+to constant fold the constants, to do semantic checks (e.g., verify bitfield
+size is non-negative and that case statements aren't duplicated). We aim for
+Clang to be very pedantic about this, diagnosing cases when the code does not
+use an i-c-e where one is required, but accepting the code unless running with
+``-pedantic-errors``.
+
+Things get a little bit more tricky when it comes to compatibility with
+real-world source code. Specifically, GCC has historically accepted a huge
+superset of expressions as i-c-e's, and a lot of real world code depends on
+this unfortuate accident of history (including, e.g., the glibc system
+headers). GCC accepts anything its "fold" optimizer is capable of reducing to
+an integer constant, which means that the definition of what it accepts changes
+as its optimizer does. One example is that GCC accepts things like "``case
+X-X:``" even when ``X`` is a variable, because it can fold this to 0.
+
+Another issue are how constants interact with the extensions we support, such
+as ``__builtin_constant_p``, ``__builtin_inf``, ``__extension__`` and many
+others. C99 obviously does not specify the semantics of any of these
+extensions, and the definition of i-c-e does not include them. However, these
+extensions are often used in real code, and we have to have a way to reason
+about them.
+
+Finally, this is not just a problem for semantic analysis. The code generator
+and other clients have to be able to fold constants (e.g., to initialize global
+variables) and has to handle a superset of what C99 allows. Further, these
+clients can benefit from extended information. For example, we know that
+"``foo() || 1``" always evaluates to ``true``, but we can't replace the
+expression with ``true`` because it has side effects.
+
+Implementation Approach
+^^^^^^^^^^^^^^^^^^^^^^^
+
+After trying several different approaches, we've finally converged on a design
+(Note, at the time of this writing, not all of this has been implemented,
+consider this a design goal!). Our basic approach is to define a single
+recursive method evaluation method (``Expr::Evaluate``), which is implemented
+in ``AST/ExprConstant.cpp``. Given an expression with "scalar" type (integer,
+fp, complex, or pointer) this method returns the following information:
+
+* Whether the expression is an integer constant expression, a general constant
+ that was folded but has no side effects, a general constant that was folded
+ but that does have side effects, or an uncomputable/unfoldable value.
+* If the expression was computable in any way, this method returns the
+ ``APValue`` for the result of the expression.
+* If the expression is not evaluatable at all, this method returns information
+ on one of the problems with the expression. This includes a
+ ``SourceLocation`` for where the problem is, and a diagnostic ID that explains
+ the problem. The diagnostic should have ``ERROR`` type.
+* If the expression is not an integer constant expression, this method returns
+ information on one of the problems with the expression. This includes a
+ ``SourceLocation`` for where the problem is, and a diagnostic ID that
+ explains the problem. The diagnostic should have ``EXTENSION`` type.
+
+This information gives various clients the flexibility that they want, and we
+will eventually have some helper methods for various extensions. For example,
+``Sema`` should have a ``Sema::VerifyIntegerConstantExpression`` method, which
+calls ``Evaluate`` on the expression. If the expression is not foldable, the
+error is emitted, and it would return ``true``. If the expression is not an
+i-c-e, the ``EXTENSION`` diagnostic is emitted. Finally it would return
+``false`` to indicate that the AST is OK.
+
+Other clients can use the information in other ways, for example, codegen can
+just use expressions that are foldable in any way.
+
+Extensions
+^^^^^^^^^^
+
+This section describes how some of the various extensions Clang supports
+interacts with constant evaluation:
+
+* ``__extension__``: The expression form of this extension causes any
+ evaluatable subexpression to be accepted as an integer constant expression.
+* ``__builtin_constant_p``: This returns true (as an integer constant
+ expression) if the operand evaluates to either a numeric value (that is, not
+ a pointer cast to integral type) of integral, enumeration, floating or
+ complex type, or if it evaluates to the address of the first character of a
+ string literal (possibly cast to some other type). As a special case, if
+ ``__builtin_constant_p`` is the (potentially parenthesized) condition of a
+ conditional operator expression ("``?:``"), only the true side of the
+ conditional operator is considered, and it is evaluated with full constant
+ folding.
+* ``__builtin_choose_expr``: The condition is required to be an integer
+ constant expression, but we accept any constant as an "extension of an
+ extension". This only evaluates one operand depending on which way the
+ condition evaluates.
+* ``__builtin_classify_type``: This always returns an integer constant
+ expression.
+* ``__builtin_inf, nan, ...``: These are treated just like a floating-point
+ literal.
+* ``__builtin_abs, copysign, ...``: These are constant folded as general
+ constant expressions.
+* ``__builtin_strlen`` and ``strlen``: These are constant folded as integer
+ constant expressions if the argument is a string literal.
+
+.. _Sema:
+
+The Sema Library
+================
+
+This library is called by the :ref:`Parser library <Parser>` during parsing to
+do semantic analysis of the input. For valid programs, Sema builds an AST for
+parsed constructs.
+
+.. _CodeGen:
+
+The CodeGen Library
+===================
+
+CodeGen takes an :ref:`AST <AST>` as input and produces `LLVM IR code
+<//llvm.org/docs/LangRef.html>`_ from it.
+
+How to change Clang
+===================
+
+How to add an attribute
+-----------------------
+Attributes are a form of metadata that can be attached to a program construct,
+allowing the programmer to pass semantic information along to the compiler for
+various uses. For example, attributes may be used to alter the code generation
+for a program construct, or to provide extra semantic information for static
+analysis. This document explains how to add a custom attribute to Clang.
+Documentation on existing attributes can be found `here
+<//clang.llvm.org/docs/AttributeReference.html>`_.
+
+Attribute Basics
+^^^^^^^^^^^^^^^^
+Attributes in Clang are handled in three stages: parsing into a parsed attribute
+representation, conversion from a parsed attribute into a semantic attribute,
+and then the semantic handling of the attribute.
+
+Parsing of the attribute is determined by the various syntactic forms attributes
+can take, such as GNU, C++11, and Microsoft style attributes, as well as other
+information provided by the table definition of the attribute. Ultimately, the
+parsed representation of an attribute object is an ``AttributeList`` object.
+These parsed attributes chain together as a list of parsed attributes attached
+to a declarator or declaration specifier. The parsing of attributes is handled
+automatically by Clang, except for attributes spelled as keywords. When
+implementing a keyword attribute, the parsing of the keyword and creation of the
+``AttributeList`` object must be done manually.
+
+Eventually, ``Sema::ProcessDeclAttributeList()`` is called with a ``Decl`` and
+an ``AttributeList``, at which point the parsed attribute can be transformed
+into a semantic attribute. The process by which a parsed attribute is converted
+into a semantic attribute depends on the attribute definition and semantic
+requirements of the attribute. The end result, however, is that the semantic
+attribute object is attached to the ``Decl`` object, and can be obtained by a
+call to ``Decl::getAttr<T>()``.
+
+The structure of the semantic attribute is also governed by the attribute
+definition given in Attr.td. This definition is used to automatically generate
+functionality used for the implementation of the attribute, such as a class
+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
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?view=markup>`_.
+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
+representation. (Note that this document does not cover the creation of type
+attributes.) An attribute that inherits from ``IgnoredAttr`` is parsed, but will
+generate an ignored attribute diagnostic when used, which may be useful when an
+attribute is supported by another vendor but not supported by clang.
+
+The definition will specify several key pieces of information, such as the
+semantic name of the attribute, the spellings the attribute supports, the
+arguments the attribute expects, and more. Most members of the ``Attr`` tablegen
+type do not require definitions in the derived definition as the default
+suffice. However, every attribute must specify at least a spelling list, a
+subject list, and a documentation list.
+
+Spellings
+~~~~~~~~~
+All attributes are required to specify a spelling list that denotes the ways in
+which the attribute can be spelled. For instance, a single semantic attribute
+may have a keyword spelling, as well as a C++11 spelling and a GNU spelling. An
+empty spelling list is also permissible and may be useful for attributes which
+are created implicitly. The following spellings are accepted:
+
+ ============ ================================================================
+ Spelling Description
+ ============ ================================================================
+ ``GNU`` Spelled with a GNU-style ``__attribute__((attr))`` syntax and
+ placement.
+ ``CXX11`` Spelled with a C++-style ``[[attr]]`` syntax. If the attribute
+ is meant to be used by Clang, it should set the namespace to
+ ``"clang"``.
+ ``Declspec`` Spelled with a Microsoft-style ``__declspec(attr)`` syntax.
+ ``Keyword`` The attribute is spelled as a keyword, and required custom
+ parsing.
+ ``GCC`` Specifies two spellings: the first is a GNU-style spelling, and
+ the second is a C++-style spelling with the ``gnu`` namespace.
+ Attributes should only specify this spelling for attributes
+ supported by GCC.
+ ``Pragma`` The attribute is spelled as a ``#pragma``, and requires custom
+ processing within the preprocessor. If the attribute is meant to
+ be used by Clang, it should set the namespace to ``"clang"``.
+ Note that this spelling is not used for declaration attributes.
+ ============ ================================================================
+
+Subjects
+~~~~~~~~
+Attributes appertain to one or more ``Decl`` subjects. If the attribute attempts
+to attach to a subject that is not in the subject list, a diagnostic is issued
+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/AttributeList.h
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/AttributeList.h?view=markup>`_
+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
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?view=markup>`_
+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
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttdDocs.td?view=markup>`_
+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
+types must specify a documentation category and the actual documentation itself.
+Additionally, it can specify a custom heading for the attribute, though a
+default heading will be chosen when possible.
+
+There are four predefined documentation categories: ``DocCatFunction`` for
+attributes that appertain to function-like subjects, ``DocCatVariable`` for
+attributes that appertain to variable-like subjects, ``DocCatType`` for type
+attributes, and ``DocCatStmt`` for statement attributes. A custom documentation
+category should be used for groups of attributes with similar functionality.
+Custom categories are good for providing overview information for the attributes
+grouped under it. For instance, the consumed annotation attributes define a
+custom category, ``DocCatConsumed``, that explains what consumed annotations are
+at a high level.
+
+Documentation content (whether it is for an attribute or a category) is written
+using reStructuredText (RST) syntax.
+
+After writing the documentation for the attribute, it should be locally tested
+to ensure that there are no issues generating the documentation on the server.
+Local testing requires a fresh build of clang-tblgen. To generate the attribute
+documentation, execute the following command::
+
+ clang-tblgen -gen-attr-docs -I /path/to/clang/include /path/to/clang/include/clang/Basic/Attr.td -o /path/to/clang/docs/AttributeReference.rst
+
+When testing locally, *do not* commit changes to ``AttributeReference.rst``.
+This file is generated by the server automatically, and any changes made to this
+file will be overwritten.
+
+Arguments
+~~~~~~~~~
+Attributes may optionally specify a list of arguments that can be passed to the
+attribute. Attribute arguments specify both the parsed form and the semantic
+form of the attribute. For example, if ``Args`` is
+``[StringArgument<"Arg1">, IntArgument<"Arg2">]`` then
+``__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
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp?view=markup>`_
+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()
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?view=markup>`_
+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 the attribute should not be propagated from from a template declaration to an
+instantiation of the template, set the ``Clone`` member to 0. By default, all
+attributes will be cloned to template instantiations.
+
+Attributes that do not require an AST node should set the ``ASTNode`` field to
+``0`` to avoid polluting the AST. Note that anything inheriting from
+``TypeAttr`` or ``IgnoredAttr`` automatically do not generate an AST node. All
+other attributes generate an AST node by default. The AST node is the semantic
+representation of the attribute.
+
+The ``LangOpts`` field specifies a list of language options required by the
+attribute. For instance, all of the CUDA-specific attributes specify ``[CUDA]``
+for the ``LangOpts`` field, and when the CUDA language option is not enabled, an
+"attribute ignored" warning diagnostic is emitted. Since language options are
+not table generated nodes, new language options must be created manually and
+should specify the spelling used by ``LangOptions`` class.
+
+Custom accessors can be generated for an attribute based on the spelling list
+for that attribute. For instance, if an attribute has two different spellings:
+'Foo' and 'Bar', accessors can be created:
+``[Accessor<"isFoo", [GNU<"Foo">]>, Accessor<"isBar", [GNU<"Bar">]>]``
+These accessors will be generated on the semantic form of the attribute,
+accepting no arguments and returning a ``bool``.
+
+Attributes that do not require custom semantic handling should set the
+``SemaHandler`` field to ``0``. Note that anything inheriting from
+``IgnoredAttr`` automatically do not get a semantic handler. All other
+attributes are assumed to use a semantic handler by default. Attributes
+without a semantic handler are not given a parsed attribute ``Kind`` enumerator.
+
+Target-specific attributes may share a spelling with other attributes in
+different targets. For instance, the ARM and MSP430 targets both have an
+attribute spelled ``GNU<"interrupt">``, but with different parsing and semantic
+requirements. To support this feature, an attribute inheriting from
+``TargetSpecificAttribute`` may specify a ``ParseKind`` field. This field
+should be the same value between all arguments sharing a spelling, and
+corresponds to the parsed attribute's ``Kind`` enumerator. This allows
+attributes to share a parsed attribute kind, but have distinct semantic
+attribute classes. For instance, ``AttributeList::AT_Interrupt`` is the shared
+parsed attribute kind, but ARMInterruptAttr and MSP430InterruptAttr are the
+semantic attributes generated.
+
+By default, when declarations are merging attributes, an attribute will not be
+duplicated. However, if an attribute can be duplicated during this merging
+stage, set ``DuplicatesAllowedWhileMerging`` to ``1``, and the attribute will
+be merged.
+
+By default, attribute arguments are parsed in an evaluated context. If the
+arguments for an attribute should be parsed in an unevaluated context (akin to
+the way the argument to a ``sizeof`` expression is parsed), set
+``ParseArgumentsAsUnevaluated`` to ``1``.
+
+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
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?view=markup>`_,
+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
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?view=markup>`_
+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
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?view=markup>`_
+
+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
+instance, to modify the way code is generated, or to add extra semantic checks
+for an analysis pass, etc. Having added the attribute definition and conversion
+to the semantic representation for the attribute, what remains is to implement
+the custom logic requiring use of the attribute.
+
+The ``clang::Decl`` object can be queried for the presence or absence of an
+attribute using ``hasAttr<T>()``. To obtain a pointer to the semantic
+representation of the attribute, ``getAttr<T>`` may be used.
+
+How to add an expression or statement
+-------------------------------------
+
+Expressions and statements are one of the most fundamental constructs within a
+compiler, because they interact with many different parts of the AST, semantic
+analysis, and IR generation. Therefore, adding a new expression or statement
+kind into Clang requires some care. The following list details the various
+places in Clang where an expression or statement needs to be introduced, along
+with patterns to follow to ensure that the new expression or statement works
+well across all of the C languages. We focus on expressions, but statements
+are similar.
+
+#. Introduce parsing actions into the parser. Recursive-descent parsing is
+ mostly self-explanatory, but there are a few things that are worth keeping
+ in mind:
+
+ * Keep as much source location information as possible! You'll want it later
+ to produce great diagnostics and support Clang's various features that map
+ between source code and the AST.
+ * Write tests for all of the "bad" parsing cases, to make sure your recovery
+ is good. If you have matched delimiters (e.g., parentheses, square
+ brackets, etc.), use ``Parser::BalancedDelimiterTracker`` to give nice
+ diagnostics when things go wrong.
+
+#. Introduce semantic analysis actions into ``Sema``. Semantic analysis should
+ always involve two functions: an ``ActOnXXX`` function that will be called
+ directly from the parser, and a ``BuildXXX`` function that performs the
+ actual semantic analysis and will (eventually!) build the AST node. It's
+ fairly common for the ``ActOnCXX`` function to do very little (often just
+ some minor translation from the parser's representation to ``Sema``'s
+ representation of the same thing), but the separation is still important:
+ C++ template instantiation, for example, should always call the ``BuildXXX``
+ variant. Several notes on semantic analysis before we get into construction
+ of the AST:
+
+ * Your expression probably involves some types and some subexpressions.
+ Make sure to fully check that those types, and the types of those
+ subexpressions, meet your expectations. Add implicit conversions where
+ necessary to make sure that all of the types line up exactly the way you
+ want them. Write extensive tests to check that you're getting good
+ diagnostics for mistakes and that you can use various forms of
+ subexpressions with your expression.
+ * When type-checking a type or subexpression, make sure to first check
+ whether the type is "dependent" (``Type::isDependentType()``) or whether a
+ subexpression is type-dependent (``Expr::isTypeDependent()``). If any of
+ these return ``true``, then you're inside a template and you can't do much
+ type-checking now. That's normal, and your AST node (when you get there)
+ will have to deal with this case. At this point, you can write tests that
+ use your expression within templates, but don't try to instantiate the
+ templates.
+ * For each subexpression, be sure to call ``Sema::CheckPlaceholderExpr()``
+ to deal with "weird" expressions that don't behave well as subexpressions.
+ Then, determine whether you need to perform lvalue-to-rvalue conversions
+ (``Sema::DefaultLvalueConversions``) or the usual unary conversions
+ (``Sema::UsualUnaryConversions``), for places where the subexpression is
+ producing a value you intend to use.
+ * Your ``BuildXXX`` function will probably just return ``ExprError()`` at
+ this point, since you don't have an AST. That's perfectly fine, and
+ shouldn't impact your testing.
+
+#. Introduce an AST node for your new expression. This starts with declaring
+ the node in ``include/Basic/StmtNodes.td`` and creating a new class for your
+ expression in the appropriate ``include/AST/Expr*.h`` header. It's best to
+ look at the class for a similar expression to get ideas, and there are some
+ specific things to watch for:
+
+ * If you need to allocate memory, use the ``ASTContext`` allocator to
+ allocate memory. Never use raw ``malloc`` or ``new``, and never hold any
+ resources in an AST node, because the destructor of an AST node is never
+ called.
+ * Make sure that ``getSourceRange()`` covers the exact source range of your
+ expression. This is needed for diagnostics and for IDE support.
+ * Make sure that ``children()`` visits all of the subexpressions. This is
+ important for a number of features (e.g., IDE support, C++ variadic
+ templates). If you have sub-types, you'll also need to visit those
+ sub-types in ``RecursiveASTVisitor``.
+ * Add printing support (``StmtPrinter.cpp``) for your expression.
+ * Add profiling support (``StmtProfile.cpp``) for your AST node, noting the
+ distinguishing (non-source location) characteristics of an instance of
+ your expression. Omitting this step will lead to hard-to-diagnose
+ failures regarding matching of template declarations.
+ * Add serialization support (``ASTReaderStmt.cpp``, ``ASTWriterStmt.cpp``)
+ for your AST node.
+
+#. Teach semantic analysis to build your AST node. At this point, you can wire
+ up your ``Sema::BuildXXX`` function to actually create your AST. A few
+ things to check at this point:
+
+ * If your expression can construct a new C++ class or return a new
+ Objective-C object, be sure to update and then call
+ ``Sema::MaybeBindToTemporary`` for your just-created AST node to be sure
+ that the object gets properly destructed. An easy way to test this is to
+ return a C++ class with a private destructor: semantic analysis should
+ flag an error here with the attempt to call the destructor.
+ * Inspect the generated AST by printing it using ``clang -cc1 -ast-print``,
+ to make sure you're capturing all of the important information about how
+ the AST was written.
+ * Inspect the generated AST under ``clang -cc1 -ast-dump`` to verify that
+ all of the types in the generated AST line up the way you want them.
+ Remember that clients of the AST should never have to "think" to
+ understand what's going on. For example, all implicit conversions should
+ show up explicitly in the AST.
+ * Write tests that use your expression as a subexpression of other,
+ well-known expressions. Can you call a function using your expression as
+ an argument? Can you use the ternary operator?
+
+#. Teach code generation to create IR to your AST node. This step is the first
+ (and only) that requires knowledge of LLVM IR. There are several things to
+ keep in mind:
+
+ * Code generation is separated into scalar/aggregate/complex and
+ lvalue/rvalue paths, depending on what kind of result your expression
+ produces. On occasion, this requires some careful factoring of code to
+ avoid duplication.
+ * ``CodeGenFunction`` contains functions ``ConvertType`` and
+ ``ConvertTypeForMem`` that convert Clang's types (``clang::Type*`` or
+ ``clang::QualType``) to LLVM types. Use the former for values, and the
+ later for memory locations: test with the C++ "``bool``" type to check
+ this. If you find that you are having to use LLVM bitcasts to make the
+ subexpressions of your expression have the type that your expression
+ expects, STOP! Go fix semantic analysis and the AST so that you don't
+ need these bitcasts.
+ * The ``CodeGenFunction`` class has a number of helper functions to make
+ certain operations easy, such as generating code to produce an lvalue or
+ an rvalue, or to initialize a memory location with a given value. Prefer
+ to use these functions rather than directly writing loads and stores,
+ because these functions take care of some of the tricky details for you
+ (e.g., for exceptions).
+ * If your expression requires some special behavior in the event of an
+ exception, look at the ``push*Cleanup`` functions in ``CodeGenFunction``
+ to introduce a cleanup. You shouldn't have to deal with
+ exception-handling directly.
+ * Testing is extremely important in IR generation. Use ``clang -cc1
+ -emit-llvm`` and `FileCheck
+ <http://llvm.org/docs/CommandGuide/FileCheck.html>`_ to verify that you're
+ generating the right IR.
+
+#. Teach template instantiation how to cope with your AST node, which requires
+ some fairly simple code:
+
+ * Make sure that your expression's constructor properly computes the flags
+ for type dependence (i.e., the type your expression produces can change
+ from one instantiation to the next), value dependence (i.e., the constant
+ value your expression produces can change from one instantiation to the
+ next), instantiation dependence (i.e., a template parameter occurs
+ anywhere in your expression), and whether your expression contains a
+ parameter pack (for variadic templates). Often, computing these flags
+ just means combining the results from the various types and
+ subexpressions.
+ * Add ``TransformXXX`` and ``RebuildXXX`` functions to the ``TreeTransform``
+ class template in ``Sema``. ``TransformXXX`` should (recursively)
+ transform all of the subexpressions and types within your expression,
+ using ``getDerived().TransformYYY``. If all of the subexpressions and
+ types transform without error, it will then call the ``RebuildXXX``
+ function, which will in turn call ``getSema().BuildXXX`` to perform
+ semantic analysis and build your expression.
+ * To test template instantiation, take those tests you wrote to make sure
+ that you were type checking with type-dependent expressions and dependent
+ types (from step #2) and instantiate those templates with various types,
+ some of which type-check and some that don't, and test the error messages
+ in each case.
+
+#. There are some "extras" that make other features work better. It's worth
+ handling these extras to give your expression complete integration into
+ Clang:
+
+ * Add code completion support for your expression in
+ ``SemaCodeComplete.cpp``.
+ * If your expression has types in it, or has any "interesting" features
+ other than subexpressions, extend libclang's ``CursorVisitor`` to provide
+ proper visitation for your expression, enabling various IDE features such
+ as syntax highlighting, cross-referencing, and so on. The
+ ``c-index-test`` helper program can be used to test these features.
+
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/IntroductionToTheClangAST.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/IntroductionToTheClangAST.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/IntroductionToTheClangAST.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/IntroductionToTheClangAST.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,126 @@
+=============================
+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>
+
+`Slides <http://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++
+standard. For example, parenthesis expressions and compile time
+constants are available in an unreduced form in the AST. This makes
+Clang's AST a good fit for refactoring tools.
+
+Documentation for all Clang AST nodes is available via the generated
+`Doxygen <http://clang.llvm.org/doxygen>`_. The doxygen online
+documentation is also indexed by your favorite search engine, which will
+make a search for clang and the AST node's class name usually turn up
+the doxygen of the class you're looking for (for example, search for:
+clang ParenExpr).
+
+Examining the AST
+=================
+
+A good way to familarize yourself with the Clang AST is to actually look
+at it on some simple example code. Clang has a builtin AST-dump mode,
+which can be enabled with the flag ``-ast-dump``.
+
+Let's look at a simple example AST:
+
+::
+
+ $ cat test.cc
+ int f(int x) {
+ int result = (x / 42);
+ return result;
+ }
+
+ # Clang by default is a frontend for many tools; -Xclang is used to pass
+ # options directly to the C++ frontend.
+ $ clang -Xclang -ast-dump -fsyntax-only test.cc
+ TranslationUnitDecl 0x5aea0d0 <<invalid sloc>>
+ ... cutting out internal declarations of clang ...
+ `-FunctionDecl 0x5aeab50 <test.cc:1:1, line:4:1> f 'int (int)'
+ |-ParmVarDecl 0x5aeaa90 <line:1:7, col:11> x 'int'
+ `-CompoundStmt 0x5aead88 <col:14, line:4:1>
+ |-DeclStmt 0x5aead10 <line:2:3, col:24>
+ | `-VarDecl 0x5aeac10 <col:3, col:23> result 'int'
+ | `-ParenExpr 0x5aeacf0 <col:16, col:23> 'int'
+ | `-BinaryOperator 0x5aeacc8 <col:17, col:21> 'int' '/'
+ | |-ImplicitCastExpr 0x5aeacb0 <col:17> 'int' <LValueToRValue>
+ | | `-DeclRefExpr 0x5aeac68 <col:17> 'int' lvalue ParmVar 0x5aeaa90 'x' 'int'
+ | `-IntegerLiteral 0x5aeac90 <col:21> 'int' 42
+ `-ReturnStmt 0x5aead68 <line:3:3, col:10>
+ `-ImplicitCastExpr 0x5aead50 <col:10> 'int' <LValueToRValue>
+ `-DeclRefExpr 0x5aead28 <col:10> 'int' lvalue Var 0x5aeac10 'result' 'int'
+
+The toplevel declaration in
+a translation unit is always the `translation unit
+declaration <http://clang.llvm.org/doxygen/classclang_1_1TranslationUnitDecl.html>`_.
+In this example, our first user written declaration is the `function
+declaration <http://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html>`_
+of "``f``". The body of "``f``" is a `compound
+statement <http://clang.llvm.org/doxygen/classclang_1_1CompoundStmt.html>`_,
+whose child nodes are a `declaration
+statement <http://clang.llvm.org/doxygen/classclang_1_1DeclStmt.html>`_
+that declares our result variable, and the `return
+statement <http://clang.llvm.org/doxygen/classclang_1_1ReturnStmt.html>`_.
+
+AST Context
+===========
+
+All information about the AST for a translation unit is bundled up in
+the class
+`ASTContext <http://clang.llvm.org/doxygen/classclang_1_1ASTContext.html>`_.
+It allows traversal of the whole translation unit starting from
+`getTranslationUnitDecl <http://clang.llvm.org/doxygen/classclang_1_1ASTContext.html#abd909fb01ef10cfd0244832a67b1dd64>`_,
+or to access Clang's `table of
+identifiers <http://clang.llvm.org/doxygen/classclang_1_1ASTContext.html#a4f95adb9958e22fbe55212ae6482feb4>`_
+for the parsed translation unit.
+
+AST Nodes
+=========
+
+Clang's AST nodes are modeled on a class hierarchy that does not have a
+common ancestor. Instead, there are multiple larger hierarchies for
+basic node types like
+`Decl <http://clang.llvm.org/doxygen/classclang_1_1Decl.html>`_ and
+`Stmt <http://clang.llvm.org/doxygen/classclang_1_1Stmt.html>`_. Many
+important AST nodes derive from
+`Type <http://clang.llvm.org/doxygen/classclang_1_1Type.html>`_,
+`Decl <http://clang.llvm.org/doxygen/classclang_1_1Decl.html>`_,
+`DeclContext <http://clang.llvm.org/doxygen/classclang_1_1DeclContext.html>`_
+or `Stmt <http://clang.llvm.org/doxygen/classclang_1_1Stmt.html>`_, with
+some classes deriving from both Decl and DeclContext.
+
+There are also a multitude of nodes in the AST that are not part of a
+larger hierarchy, and are only reachable from specific other nodes, like
+`CXXBaseSpecifier <http://clang.llvm.org/doxygen/classclang_1_1CXXBaseSpecifier.html>`_.
+
+Thus, to traverse the full AST, one starts from the
+`TranslationUnitDecl <http://clang.llvm.org/doxygen/classclang_1_1TranslationUnitDecl.html>`_
+and then recursively traverses everything that can be reached from that
+node - this information has to be encoded for each specific node type.
+This algorithm is encoded in the
+`RecursiveASTVisitor <http://clang.llvm.org/doxygen/classclang_1_1RecursiveASTVisitor.html>`_.
+See the `RecursiveASTVisitor
+tutorial <http://clang.llvm.org/docs/RAVFrontendAction.html>`_.
+
+The two most basic nodes in the Clang AST are statements
+(`Stmt <http://clang.llvm.org/doxygen/classclang_1_1Stmt.html>`_) and
+declarations
+(`Decl <http://clang.llvm.org/doxygen/classclang_1_1Decl.html>`_). Note
+that expressions
+(`Expr <http://clang.llvm.org/doxygen/classclang_1_1Expr.html>`_) are
+also statements in Clang's AST.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/ItaniumMangleAbiTags.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/ItaniumMangleAbiTags.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/ItaniumMangleAbiTags.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/ItaniumMangleAbiTags.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,107 @@
+========
+ABI tags
+========
+
+Introduction
+============
+
+This text tries to describe gcc semantic for mangling "abi_tag" attributes
+described in https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
+
+There is no guarantee the following rules are correct, complete or make sense
+in any way as they were determined empirically by experiments with gcc5.
+
+Declaration
+===========
+
+ABI tags are declared in an abi_tag attribute and can be applied to a
+function, variable, class or inline namespace declaration. The attribute takes
+one or more strings (called tags); the order does not matter.
+
+See https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html for
+details.
+
+Tags on an inline namespace are called "implicit tags", all other tags are
+"explicit tags".
+
+Mangling
+========
+
+All tags that are "active" on an <unqualified-name> are emitted after the
+<unqualified-name>, before <template-args> or <discriminator>, and are part of
+the same <substitution> the <unqualified-name> is.
+
+They are mangled as:
+
+.. code-block:: none
+
+ <abi-tags> ::= <abi-tag>* # sort by name
+ <abi-tag> ::= B <tag source-name>
+
+Example:
+
+.. code-block:: c++
+
+ __attribute__((abi_tag("test")))
+ void Func();
+ // gets mangled as: _Z4FuncB4testv (prettified as `Func[abi:test]()`)
+
+Active tags
+===========
+
+A namespace does not have any active tags. For types (class / struct / union /
+enum), the explicit tags are the active tags.
+
+For variables and functions, the active tags are the explicit tags plus any
+"required tags" which are not in the "available tags" set:
+
+.. code-block:: none
+
+ derived-tags := (required-tags - available-tags)
+ active-tags := explicit-tags + derived-tags
+
+Required tags for a function
+============================
+
+If a function is used as a local scope for another name, and is part of
+another function as local scope, it doesn't have any required tags.
+
+If a function is used as a local scope for a guard variable name, it doesn't
+have any required tags.
+
+Otherwise the function requires any implicit or explicit tag used in the name
+for the return type.
+
+Example:
+
+.. code-block:: c++
+
+ namespace A {
+ inline namespace B __attribute__((abi_tag)) {
+ struct C { int x; };
+ }
+ }
+
+ A::C foo(); // gets mangled as: _Z3fooB1Bv (prettified as `foo[abi:B]()`)
+
+Required tags for a variable
+============================
+
+A variable requires any implicit or explicit tag used in its type.
+
+Available tags
+==============
+
+All tags used in the prefix and in the template arguments for a name are
+available. Also, for functions, all tags from the <bare-function-type>
+(which might include the return type for template functions) are available.
+
+For <local-name>s all active tags used in the local part (<function-
+encoding>) are available, but not implicit tags which were not active.
+
+Implicit and explicit tags used in the <unqualified-name> for a function (as
+in the type of a cast operator) are NOT available.
+
+Example: a cast operator to std::string (which is
+std::__cxx11::basic_string<...>) will use 'cxx11' as an active tag, as it is
+required from the return type `std::string` but not available.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/JSONCompilationDatabase.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/JSONCompilationDatabase.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/JSONCompilationDatabase.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/JSONCompilationDatabase.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,93 @@
+==============================================
+JSON Compilation Database Format Specification
+==============================================
+
+This document describes a format for specifying how to replay single
+compilations independently of the build system.
+
+Background
+==========
+
+Tools based on the C++ Abstract Syntax Tree need full information how to
+parse a translation unit. Usually this information is implicitly
+available in the build system, but running tools as part of the build
+system is not necessarily the best solution:
+
+- Build systems are inherently change driven, so running multiple tools
+ over the same code base without changing the code does not fit into
+ the architecture of many build systems.
+- Figuring out whether things have changed is often an IO bound
+ process; this makes it hard to build low latency end user tools based
+ on the build system.
+- Build systems are inherently sequential in the build graph, for
+ example due to generated source code. While tools that run
+ 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
+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
+python bindings also support this (since clang 3.2); see
+`CXCompilationDatabase.h </doxygen/group__COMPILATIONDB.html>`_.
+
+Format
+======
+
+A compilation database is a JSON file, which consist of an array of
+"command objects", where each command object specifies one way a
+translation unit is compiled in the project.
+
+Each command object contains the translation unit's main file, the
+working directory of the compile run and the actual compile command.
+
+Example:
+
+::
+
+ [
+ { "directory": "/home/user/llvm/build",
+ "command": "/usr/bin/clang++ -Irelative -DSOMEDEF=\"With spaces, quotes and \\-es.\" -c -o file.o file.cc",
+ "file": "file.cc" },
+ ...
+ ]
+
+The contracts for each field in the command object are:
+
+- **directory:** The working directory of the compilation. All paths
+ specified in the **command** or **file** fields must be either
+ absolute or relative to this directory.
+- **file:** The main translation unit source processed by this
+ compilation step. This is used by tools as the key into the
+ compilation database. There can be multiple command objects for the
+ same file, for example if the same source file is compiled with
+ different configurations.
+- **command:** The compile command executed. After JSON unescaping,
+ this must be a valid command to rerun the exact compilation step for
+ the translation unit in the environment the build system uses.
+ Parameters use shell quoting and shell escaping of quotes, with '``"``'
+ and '``\``' being the only special characters. Shell expansion is not
+ supported.
+- **arguments:** The compile command executed as list of strings.
+ Either **arguments** or **command** is required.
+- **output:** The name of the output created by this compilation step.
+ This field is optional. It can be used to distinguish different processing
+ modes of the same input file.
+
+Build System Integration
+========================
+
+The convention is to name the file compile\_commands.json and put it at
+the top of the build directory. Clang tools are pointed to the top of
+the build directory to detect the file and use the compilation database
+to parse C++ code in the source tree.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/LTOVisibility.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/LTOVisibility.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/LTOVisibility.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/LTOVisibility.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,114 @@
+==============
+LTO Visibility
+==============
+
+*LTO visibility* is a property of an entity that specifies whether it can be
+referenced from outside the current LTO unit. A *linkage unit* is a set of
+translation units linked together into an executable or DSO, and a linkage
+unit's *LTO unit* is the subset of the linkage unit that is linked together
+using link-time optimization; in the case where LTO is not being used, the
+linkage unit's LTO unit is empty. Each linkage unit has only a single LTO unit.
+
+The LTO visibility of a class is used by the compiler to determine which
+classes the whole-program devirtualization (``-fwhole-program-vtables``) and
+control flow integrity (``-fsanitize=cfi-vcall``) features apply to. These
+features use whole-program information, so they require the entire class
+hierarchy to be visible in order to work correctly.
+
+If any translation unit in the program uses either of the whole-program
+devirtualization or control flow integrity features, it is effectively an ODR
+violation to define a class with hidden LTO visibility in multiple linkage
+units. A class with public LTO visibility may be defined in multiple linkage
+units, but the tradeoff is that the whole-program devirtualization and
+control flow integrity features can only be applied to classes with hidden LTO
+visibility. A class's LTO visibility is treated as an ODR-relevant property
+of its definition, so it must be consistent between translation units.
+
+In translation units built with LTO, LTO visibility is based on the
+class's symbol visibility as expressed at the source level (i.e. the
+``__attribute__((visibility("...")))`` attribute, or the ``-fvisibility=``
+flag) or, on the Windows platform, the dllimport and dllexport attributes. When
+targeting non-Windows platforms, classes with a visibility other than hidden
+visibility receive public LTO visibility. When targeting Windows, classes
+with dllimport or dllexport attributes receive public LTO visibility. All
+other classes receive hidden LTO visibility. Classes with internal linkage
+(e.g. classes declared in unnamed namespaces) also receive hidden LTO
+visibility.
+
+A class defined in a translation unit built without LTO receives public
+LTO visibility regardless of its object file visibility, linkage or other
+attributes.
+
+This mechanism will produce the correct result in most cases, but there are
+two cases where it may wrongly infer hidden LTO visibility.
+
+1. As a corollary of the above rules, if a linkage unit is produced from a
+ combination of LTO object files and non-LTO object files, any hidden
+ visibility class defined in both a translation unit built with LTO and
+ a translation unit built without LTO must be defined with public LTO
+ visibility in order to avoid an ODR violation.
+
+2. Some ABIs provide the ability to define an abstract base class without
+ visibility attributes in multiple linkage units and have virtual calls
+ to derived classes in other linkage units work correctly. One example of
+ this is COM on Windows platforms. If the ABI allows this, any base class
+ used in this way must be defined with public LTO visibility.
+
+Classes that fall into either of these categories can be marked up with the
+``[[clang::lto_visibility_public]]`` attribute. To specifically handle the
+COM case, classes with the ``__declspec(uuid())`` attribute receive public
+LTO visibility. On Windows platforms, clang-cl's ``/MT`` and ``/MTd``
+flags statically link the program against a prebuilt standard library;
+these flags imply public LTO visibility for every class declared in the
+``std`` and ``stdext`` namespaces.
+
+Example
+=======
+
+The following example shows how LTO visibility works in practice in several
+cases involving two linkage units, ``main`` and ``dso.so``.
+
+.. code-block:: none
+
+ +-----------------------------------------------------------+ +----------------------------------------------------+
+ | main (clang++ -fvisibility=hidden): | | dso.so (clang++ -fvisibility=hidden): |
+ | | | |
+ | +-----------------------------------------------------+ | | struct __attribute__((visibility("default"))) C { |
+ | | LTO unit (clang++ -fvisibility=hidden -flto): | | | virtual void f(); |
+ | | | | | } |
+ | | struct A { ... }; | | | void C::f() {} |
+ | | struct [[clang::lto_visibility_public]] B { ... }; | | | struct D { |
+ | | struct __attribute__((visibility("default"))) C { | | | virtual void g() = 0; |
+ | | virtual void f(); | | | }; |
+ | | }; | | | struct E : D { |
+ | | struct [[clang::lto_visibility_public]] D { | | | virtual void g() { ... } |
+ | | virtual void g() = 0; | | | }; |
+ | | }; | | | __attribute__(visibility("default"))) D *mkE() { |
+ | | | | | return new E; |
+ | +-----------------------------------------------------+ | | } |
+ | | | |
+ | struct B { ... }; | +----------------------------------------------------+
+ | |
+ +-----------------------------------------------------------+
+
+We will now describe the LTO visibility of each of the classes defined in
+these linkage units.
+
+Class ``A`` is not defined outside of ``main``'s LTO unit, so it can have
+hidden LTO visibility. This is inferred from the object file visibility
+specified on the command line.
+
+Class ``B`` is defined in ``main``, both inside and outside its LTO unit. The
+definition outside the LTO unit has public LTO visibility, so the definition
+inside the LTO unit must also have public LTO visibility in order to avoid
+an ODR violation.
+
+Class ``C`` is defined in both ``main`` and ``dso.so`` and therefore must
+have public LTO visibility. This is correctly inferred from the ``visibility``
+attribute.
+
+Class ``D`` is an abstract base class with a derived class ``E`` defined
+in ``dso.so``. This is an example of the COM scenario; the definition of
+``D`` in ``main``'s LTO unit must have public LTO visibility in order to be
+compatible with the definition of ``D`` in ``dso.so``, which is observable
+by calling the function ``mkE``.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/LanguageExtensions.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/LanguageExtensions.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/LanguageExtensions.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/LanguageExtensions.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,2644 @@
+=========================
+Clang Language Extensions
+=========================
+
+.. contents::
+ :local:
+ :depth: 1
+
+.. toctree::
+ :hidden:
+
+ ObjectiveCLiterals
+ BlockLanguageSpec
+ Block-ABI-Apple
+ 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
+these extensions.
+
+.. _langext-feature_check:
+
+Feature Checking Macros
+=======================
+
+Language extensions can be very useful, but only if you know you can depend on
+them. In order to allow fine-grain features checks, we support three builtin
+function-like macros. This allows you to directly test for a feature in your
+code without having to resort to something like autoconf or fragile "compiler
+version checks".
+
+``__has_builtin``
+-----------------
+
+This function-like macro takes a single identifier argument that is the name of
+a builtin function. It evaluates to 1 if the builtin is supported or 0 if not.
+It can be used like this:
+
+.. code-block:: c++
+
+ #ifndef __has_builtin // Optional of course.
+ #define __has_builtin(x) 0 // Compatibility with non-clang compilers.
+ #endif
+
+ ...
+ #if __has_builtin(__builtin_trap)
+ __builtin_trap();
+ #else
+ abort();
+ #endif
+ ...
+
+.. _langext-__has_feature-__has_extension:
+
+``__has_feature`` and ``__has_extension``
+-----------------------------------------
+
+These function-like macros take a single identifier argument that is the name
+of a feature. ``__has_feature`` evaluates to 1 if the feature is both
+supported by Clang and standardized in the current language standard or 0 if
+not (but see :ref:`below <langext-has-feature-back-compat>`), while
+``__has_extension`` evaluates to 1 if the feature is supported by Clang in the
+current language (either as a language extension or a standard language
+feature) or 0 if not. They can be used like this:
+
+.. code-block:: c++
+
+ #ifndef __has_feature // Optional of course.
+ #define __has_feature(x) 0 // Compatibility with non-clang compilers.
+ #endif
+ #ifndef __has_extension
+ #define __has_extension __has_feature // Compatibility with pre-3.0 compilers.
+ #endif
+
+ ...
+ #if __has_feature(cxx_rvalue_references)
+ // This code will only be compiled with the -std=c++11 and -std=gnu++11
+ // options, because rvalue references are only standardized in C++11.
+ #endif
+
+ #if __has_extension(cxx_rvalue_references)
+ // This code will be compiled with the -std=c++11, -std=gnu++11, -std=c++98
+ // and -std=gnu++98 options, because rvalue references are supported as a
+ // language extension in C++98.
+ #endif
+
+.. _langext-has-feature-back-compat:
+
+For backward compatibility, ``__has_feature`` can also be used to test
+for support for non-standardized features, i.e. features not prefixed ``c_``,
+``cxx_`` or ``objc_``.
+
+Another use of ``__has_feature`` is to check for compiler features not related
+to the language standard, such as e.g. :doc:`AddressSanitizer
+<AddressSanitizer>`.
+
+If the ``-pedantic-errors`` option is given, ``__has_extension`` is equivalent
+to ``__has_feature``.
+
+The feature tag is described along with the language feature below.
+
+The feature name or extension name can also be specified with a preceding and
+following ``__`` (double underscore) to avoid interference from a macro with
+the same name. For instance, ``__cxx_rvalue_references__`` can be used instead
+of ``cxx_rvalue_references``.
+
+``__has_cpp_attribute``
+-----------------------
+
+This function-like macro takes a single argument that is the name of a
+C++11-style attribute. The argument can either be a single identifier, or a
+scoped identifier. If the attribute is supported, a nonzero value is returned.
+If the attribute is a standards-based attribute, this macro returns a nonzero
+value based on the year and month in which the attribute was voted into the
+working draft. If the attribute is not supported by the current compliation
+target, this macro evaluates to 0. It can be used like this:
+
+.. code-block:: c++
+
+ #ifndef __has_cpp_attribute // Optional of course.
+ #define __has_cpp_attribute(x) 0 // Compatibility with non-clang compilers.
+ #endif
+
+ ...
+ #if __has_cpp_attribute(clang::fallthrough)
+ #define FALLTHROUGH [[clang::fallthrough]]
+ #else
+ #define FALLTHROUGH
+ #endif
+ ...
+
+The attribute identifier (but not scope) can also be specified with a preceding
+and following ``__`` (double underscore) to avoid interference from a macro with
+the same name. For instance, ``gnu::__const__`` can be used instead of
+``gnu::const``.
+
+``__has_attribute``
+-------------------
+
+This function-like macro takes a single identifier argument that is the name of
+a GNU-style attribute. It evaluates to 1 if the attribute is supported by the
+current compilation target, or 0 if not. It can be used like this:
+
+.. code-block:: c++
+
+ #ifndef __has_attribute // Optional of course.
+ #define __has_attribute(x) 0 // Compatibility with non-clang compilers.
+ #endif
+
+ ...
+ #if __has_attribute(always_inline)
+ #define ALWAYS_INLINE __attribute__((always_inline))
+ #else
+ #define ALWAYS_INLINE
+ #endif
+ ...
+
+The attribute name can also be specified with a preceding and following ``__``
+(double underscore) to avoid interference from a macro with the same name. For
+instance, ``__always_inline__`` can be used instead of ``always_inline``.
+
+
+``__has_declspec_attribute``
+----------------------------
+
+This function-like macro takes a single identifier argument that is the name of
+an attribute implemented as a Microsoft-style ``__declspec`` attribute. It
+evaluates to 1 if the attribute is supported by the current compilation target,
+or 0 if not. It can be used like this:
+
+.. code-block:: c++
+
+ #ifndef __has_declspec_attribute // Optional of course.
+ #define __has_declspec_attribute(x) 0 // Compatibility with non-clang compilers.
+ #endif
+
+ ...
+ #if __has_declspec_attribute(dllexport)
+ #define DLLEXPORT __declspec(dllexport)
+ #else
+ #define DLLEXPORT
+ #endif
+ ...
+
+The attribute name can also be specified with a preceding and following ``__``
+(double underscore) to avoid interference from a macro with the same name. For
+instance, ``__dllexport__`` can be used instead of ``dllexport``.
+
+``__is_identifier``
+-------------------
+
+This function-like macro takes a single identifier argument that might be either
+a reserved word or a regular identifier. It evaluates to 1 if the argument is just
+a regular identifier and not a reserved word, in the sense that it can then be
+used as the name of a user-defined function or variable. Otherwise it evaluates
+to 0. It can be used like this:
+
+.. code-block:: c++
+
+ ...
+ #ifdef __is_identifier // Compatibility with non-clang compilers.
+ #if __is_identifier(__wchar_t)
+ typedef wchar_t __wchar_t;
+ #endif
+ #endif
+
+ __wchar_t WideCharacter;
+ ...
+
+Include File Checking Macros
+============================
+
+Not all developments systems have the same include files. The
+:ref:`langext-__has_include` and :ref:`langext-__has_include_next` macros allow
+you to check for the existence of an include file before doing a possibly
+failing ``#include`` directive. Include file checking macros must be used
+as expressions in ``#if`` or ``#elif`` preprocessing directives.
+
+.. _langext-__has_include:
+
+``__has_include``
+-----------------
+
+This function-like macro takes a single file name string argument that is the
+name of an include file. It evaluates to 1 if the file can be found using the
+include paths, or 0 otherwise:
+
+.. code-block:: c++
+
+ // Note the two possible file name string formats.
+ #if __has_include("myinclude.h") && __has_include(<stdint.h>)
+ # include "myinclude.h"
+ #endif
+
+To test for this feature, use ``#if defined(__has_include)``:
+
+.. code-block:: c++
+
+ // To avoid problem with non-clang compilers not having this macro.
+ #if defined(__has_include)
+ #if __has_include("myinclude.h")
+ # include "myinclude.h"
+ #endif
+ #endif
+
+.. _langext-__has_include_next:
+
+``__has_include_next``
+----------------------
+
+This function-like macro takes a single file name string argument that is the
+name of an include file. It is like ``__has_include`` except that it looks for
+the second instance of the given file found in the include paths. It evaluates
+to 1 if the second instance of the file can be found using the include paths,
+or 0 otherwise:
+
+.. code-block:: c++
+
+ // Note the two possible file name string formats.
+ #if __has_include_next("myinclude.h") && __has_include_next(<stdint.h>)
+ # include_next "myinclude.h"
+ #endif
+
+ // To avoid problem with non-clang compilers not having this macro.
+ #if defined(__has_include_next)
+ #if __has_include_next("myinclude.h")
+ # include_next "myinclude.h"
+ #endif
+ #endif
+
+Note that ``__has_include_next``, like the GNU extension ``#include_next``
+directive, is intended for use in headers only, and will issue a warning if
+used in the top-level compilation file. A warning will also be issued if an
+absolute path is used in the file argument.
+
+``__has_warning``
+-----------------
+
+This function-like macro takes a string literal that represents a command line
+option for a warning and returns true if that is a valid warning option.
+
+.. code-block:: c++
+
+ #if __has_warning("-Wformat")
+ ...
+ #endif
+
+Builtin Macros
+==============
+
+``__BASE_FILE__``
+ Defined to a string that contains the name of the main input file passed to
+ Clang.
+
+``__COUNTER__``
+ Defined to an integer value that starts at zero and is incremented each time
+ the ``__COUNTER__`` macro is expanded.
+
+``__INCLUDE_LEVEL__``
+ Defined to an integral value that is the include depth of the file currently
+ being translated. For the main file, this value is zero.
+
+``__TIMESTAMP__``
+ Defined to the date and time of the last modification of the current source
+ file.
+
+``__clang__``
+ Defined when compiling with Clang
+
+``__clang_major__``
+ Defined to the major marketing version number of Clang (e.g., the 2 in
+ 2.0.1). Note that marketing version numbers should not be used to check for
+ language features, as different vendors use different numbering schemes.
+ Instead, use the :ref:`langext-feature_check`.
+
+``__clang_minor__``
+ Defined to the minor version number of Clang (e.g., the 0 in 2.0.1). Note
+ that marketing version numbers should not be used to check for language
+ features, as different vendors use different numbering schemes. Instead, use
+ the :ref:`langext-feature_check`.
+
+``__clang_patchlevel__``
+ Defined to the marketing patch level of Clang (e.g., the 1 in 2.0.1).
+
+``__clang_version__``
+ Defined to a string that captures the Clang marketing version, including the
+ Subversion tag or revision number, e.g., "``1.5 (trunk 102332)``".
+
+.. _langext-vectors:
+
+Vectors and Extended Vectors
+============================
+
+Supports the GCC, OpenCL, AltiVec and NEON vector extensions.
+
+OpenCL vector types are created using ``ext_vector_type`` attribute. It
+support for ``V.xyzw`` syntax and other tidbits as seen in OpenCL. An example
+is:
+
+.. code-block:: c++
+
+ typedef float float4 __attribute__((ext_vector_type(4)));
+ typedef float float2 __attribute__((ext_vector_type(2)));
+
+ float4 foo(float2 a, float2 b) {
+ float4 c;
+ c.xz = a;
+ c.yw = b;
+ return c;
+ }
+
+Query for this feature with ``__has_extension(attribute_ext_vector_type)``.
+
+Giving ``-maltivec`` option to clang enables support for AltiVec vector syntax
+and functions. For example:
+
+.. code-block:: c++
+
+ vector float foo(vector int a) {
+ vector int b;
+ b = vec_add(a, a) + a;
+ return (vector float)b;
+ }
+
+NEON vector types are created using ``neon_vector_type`` and
+``neon_polyvector_type`` attributes. For example:
+
+.. code-block:: c++
+
+ typedef __attribute__((neon_vector_type(8))) int8_t int8x8_t;
+ typedef __attribute__((neon_polyvector_type(16))) poly8_t poly8x16_t;
+
+ int8x8_t foo(int8x8_t a) {
+ int8x8_t v;
+ v = a;
+ return v;
+ }
+
+Vector Literals
+---------------
+
+Vector literals can be used to create vectors from a set of scalars, or
+vectors. Either parentheses or braces form can be used. In the parentheses
+form the number of literal values specified must be one, i.e. referring to a
+scalar value, or must match the size of the vector type being created. If a
+single scalar literal value is specified, the scalar literal value will be
+replicated to all the components of the vector type. In the brackets form any
+number of literals can be specified. For example:
+
+.. code-block:: c++
+
+ typedef int v4si __attribute__((__vector_size__(16)));
+ typedef float float4 __attribute__((ext_vector_type(4)));
+ typedef float float2 __attribute__((ext_vector_type(2)));
+
+ v4si vsi = (v4si){1, 2, 3, 4};
+ float4 vf = (float4)(1.0f, 2.0f, 3.0f, 4.0f);
+ vector int vi1 = (vector int)(1); // vi1 will be (1, 1, 1, 1).
+ vector int vi2 = (vector int){1}; // vi2 will be (1, 0, 0, 0).
+ vector int vi3 = (vector int)(1, 2); // error
+ vector int vi4 = (vector int){1, 2}; // vi4 will be (1, 2, 0, 0).
+ vector int vi5 = (vector int)(1, 2, 3, 4);
+ float4 vf = (float4)((float2)(1.0f, 2.0f), (float2)(3.0f, 4.0f));
+
+Vector Operations
+-----------------
+
+The table below shows the support for each operation by vector extension. A
+dash indicates that an operation is not accepted according to a corresponding
+specification.
+
+============================== ======= ======= ======= =======
+ Operator OpenCL AltiVec GCC NEON
+============================== ======= ======= ======= =======
+[] yes yes yes --
+unary operators +, -- yes yes yes --
+++, -- -- yes yes yes --
++,--,*,/,% yes yes yes --
+bitwise operators &,|,^,~ yes yes yes --
+>>,<< yes yes yes --
+!, &&, || yes -- -- --
+==, !=, >, <, >=, <= yes yes -- --
+= yes yes yes yes
+:? yes -- -- --
+sizeof yes yes yes yes
+C-style cast yes yes yes no
+reinterpret_cast yes no yes no
+static_cast yes no yes no
+const_cast no no no no
+============================== ======= ======= ======= =======
+
+See also :ref:`langext-__builtin_shufflevector`, :ref:`langext-__builtin_convertvector`.
+
+Messages on ``deprecated`` and ``unavailable`` Attributes
+=========================================================
+
+An optional string message can be added to the ``deprecated`` and
+``unavailable`` attributes. For example:
+
+.. code-block:: c++
+
+ void explode(void) __attribute__((deprecated("extremely unsafe, use 'combust' instead!!!")));
+
+If the deprecated or unavailable declaration is used, the message will be
+incorporated into the appropriate diagnostic:
+
+.. code-block:: none
+
+ harmless.c:4:3: warning: 'explode' is deprecated: extremely unsafe, use 'combust' instead!!!
+ [-Wdeprecated-declarations]
+ explode();
+ ^
+
+Query for this feature with
+``__has_extension(attribute_deprecated_with_message)`` and
+``__has_extension(attribute_unavailable_with_message)``.
+
+Attributes on Enumerators
+=========================
+
+Clang allows attributes to be written on individual enumerators. This allows
+enumerators to be deprecated, made unavailable, etc. The attribute must appear
+after the enumerator name and before any initializer, like so:
+
+.. code-block:: c++
+
+ enum OperationMode {
+ OM_Invalid,
+ OM_Normal,
+ OM_Terrified __attribute__((deprecated)),
+ OM_AbortOnError __attribute__((deprecated)) = 4
+ };
+
+Attributes on the ``enum`` declaration do not apply to individual enumerators.
+
+Query for this feature with ``__has_extension(enumerator_attributes)``.
+
+'User-Specified' System Frameworks
+==================================
+
+Clang provides a mechanism by which frameworks can be built in such a way that
+they will always be treated as being "system frameworks", even if they are not
+present in a system framework directory. This can be useful to system
+framework developers who want to be able to test building other applications
+with development builds of their framework, including the manner in which the
+compiler changes warning behavior for system headers.
+
+Framework developers can opt-in to this mechanism by creating a
+"``.system_framework``" file at the top-level of their framework. That is, the
+framework should have contents like:
+
+.. code-block:: none
+
+ .../TestFramework.framework
+ .../TestFramework.framework/.system_framework
+ .../TestFramework.framework/Headers
+ .../TestFramework.framework/Headers/TestFramework.h
+ ...
+
+Clang will treat the presence of this file as an indicator that the framework
+should be treated as a system framework, regardless of how it was found in the
+framework search path. For consistency, we recommend that such files never be
+included in installed versions of the framework.
+
+Checks for Standard Language Features
+=====================================
+
+The ``__has_feature`` macro can be used to query if certain standard language
+features are enabled. The ``__has_extension`` macro can be used to query if
+language features are available as an extension when compiling for a standard
+which does not provide them. The features which can be tested are listed here.
+
+Since Clang 3.4, the C++ SD-6 feature test macros are also supported.
+These are macros with names of the form ``__cpp_<feature_name>``, and are
+intended to be a portable way to query the supported features of the compiler.
+See `the C++ status page <http://clang.llvm.org/cxx_status.html#ts>`_ for
+information on the version of SD-6 supported by each Clang release, and the
+macros provided by that revision of the recommendations.
+
+C++98
+-----
+
+The features listed below are part of the C++98 standard. These features are
+enabled by default when compiling C++ code.
+
+C++ exceptions
+^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_exceptions)`` to determine if C++ exceptions have been
+enabled. For example, compiling code with ``-fno-exceptions`` disables C++
+exceptions.
+
+C++ RTTI
+^^^^^^^^
+
+Use ``__has_feature(cxx_rtti)`` to determine if C++ RTTI has been enabled. For
+example, compiling code with ``-fno-rtti`` disables the use of RTTI.
+
+C++11
+-----
+
+The features listed below are part of the C++11 standard. As a result, all
+these features are enabled with the ``-std=c++11`` or ``-std=gnu++11`` option
+when compiling C++ code.
+
+C++11 SFINAE includes access control
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_access_control_sfinae)`` or
+``__has_extension(cxx_access_control_sfinae)`` to determine whether
+access-control errors (e.g., calling a private constructor) are considered to
+be template argument deduction errors (aka SFINAE errors), per `C++ DR1170
+<http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1170>`_.
+
+C++11 alias templates
+^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_alias_templates)`` or
+``__has_extension(cxx_alias_templates)`` to determine if support for C++11's
+alias declarations and alias templates is enabled.
+
+C++11 alignment specifiers
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_alignas)`` or ``__has_extension(cxx_alignas)`` to
+determine if support for alignment specifiers using ``alignas`` is enabled.
+
+Use ``__has_feature(cxx_alignof)`` or ``__has_extension(cxx_alignof)`` to
+determine if support for the ``alignof`` keyword is enabled.
+
+C++11 attributes
+^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_attributes)`` or ``__has_extension(cxx_attributes)`` to
+determine if support for attribute parsing with C++11's square bracket notation
+is enabled.
+
+C++11 generalized constant expressions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_constexpr)`` to determine if support for generalized
+constant expressions (e.g., ``constexpr``) is enabled.
+
+C++11 ``decltype()``
+^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_decltype)`` or ``__has_extension(cxx_decltype)`` to
+determine if support for the ``decltype()`` specifier is enabled. C++11's
+``decltype`` does not require type-completeness of a function call expression.
+Use ``__has_feature(cxx_decltype_incomplete_return_types)`` or
+``__has_extension(cxx_decltype_incomplete_return_types)`` to determine if
+support for this feature is enabled.
+
+C++11 default template arguments in function templates
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_default_function_template_args)`` or
+``__has_extension(cxx_default_function_template_args)`` to determine if support
+for default template arguments in function templates is enabled.
+
+C++11 ``default``\ ed functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_defaulted_functions)`` or
+``__has_extension(cxx_defaulted_functions)`` to determine if support for
+defaulted function definitions (with ``= default``) is enabled.
+
+C++11 delegating constructors
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_delegating_constructors)`` to determine if support for
+delegating constructors is enabled.
+
+C++11 ``deleted`` functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_deleted_functions)`` or
+``__has_extension(cxx_deleted_functions)`` to determine if support for deleted
+function definitions (with ``= delete``) is enabled.
+
+C++11 explicit conversion functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_explicit_conversions)`` to determine if support for
+``explicit`` conversion functions is enabled.
+
+C++11 generalized initializers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_generalized_initializers)`` to determine if support for
+generalized initializers (using braced lists and ``std::initializer_list``) is
+enabled.
+
+C++11 implicit move constructors/assignment operators
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_implicit_moves)`` to determine if Clang will implicitly
+generate move constructors and move assignment operators where needed.
+
+C++11 inheriting constructors
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_inheriting_constructors)`` to determine if support for
+inheriting constructors is enabled.
+
+C++11 inline namespaces
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_inline_namespaces)`` or
+``__has_extension(cxx_inline_namespaces)`` to determine if support for inline
+namespaces is enabled.
+
+C++11 lambdas
+^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_lambdas)`` or ``__has_extension(cxx_lambdas)`` to
+determine if support for lambdas is enabled.
+
+C++11 local and unnamed types as template arguments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_local_type_template_args)`` or
+``__has_extension(cxx_local_type_template_args)`` to determine if support for
+local and unnamed types as template arguments is enabled.
+
+C++11 noexcept
+^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_noexcept)`` or ``__has_extension(cxx_noexcept)`` to
+determine if support for noexcept exception specifications is enabled.
+
+C++11 in-class non-static data member initialization
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_nonstatic_member_init)`` to determine whether in-class
+initialization of non-static data members is enabled.
+
+C++11 ``nullptr``
+^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_nullptr)`` or ``__has_extension(cxx_nullptr)`` to
+determine if support for ``nullptr`` is enabled.
+
+C++11 ``override control``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_override_control)`` or
+``__has_extension(cxx_override_control)`` to determine if support for the
+override control keywords is enabled.
+
+C++11 reference-qualified functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_reference_qualified_functions)`` or
+``__has_extension(cxx_reference_qualified_functions)`` to determine if support
+for reference-qualified functions (e.g., member functions with ``&`` or ``&&``
+applied to ``*this``) is enabled.
+
+C++11 range-based ``for`` loop
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_range_for)`` or ``__has_extension(cxx_range_for)`` to
+determine if support for the range-based for loop is enabled.
+
+C++11 raw string literals
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_raw_string_literals)`` to determine if support for raw
+string literals (e.g., ``R"x(foo\bar)x"``) is enabled.
+
+C++11 rvalue references
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_rvalue_references)`` or
+``__has_extension(cxx_rvalue_references)`` to determine if support for rvalue
+references is enabled.
+
+C++11 ``static_assert()``
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_static_assert)`` or
+``__has_extension(cxx_static_assert)`` to determine if support for compile-time
+assertions using ``static_assert`` is enabled.
+
+C++11 ``thread_local``
+^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_thread_local)`` to determine if support for
+``thread_local`` variables is enabled.
+
+C++11 type inference
+^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_auto_type)`` or ``__has_extension(cxx_auto_type)`` to
+determine C++11 type inference is supported using the ``auto`` specifier. If
+this is disabled, ``auto`` will instead be a storage class specifier, as in C
+or C++98.
+
+C++11 strongly typed enumerations
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_strong_enums)`` or
+``__has_extension(cxx_strong_enums)`` to determine if support for strongly
+typed, scoped enumerations is enabled.
+
+C++11 trailing return type
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_trailing_return)`` or
+``__has_extension(cxx_trailing_return)`` to determine if support for the
+alternate function declaration syntax with trailing return type is enabled.
+
+C++11 Unicode string literals
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_unicode_literals)`` to determine if support for Unicode
+string literals is enabled.
+
+C++11 unrestricted unions
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_unrestricted_unions)`` to determine if support for
+unrestricted unions is enabled.
+
+C++11 user-defined literals
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_user_literals)`` to determine if support for
+user-defined literals is enabled.
+
+C++11 variadic templates
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_variadic_templates)`` or
+``__has_extension(cxx_variadic_templates)`` to determine if support for
+variadic templates is enabled.
+
+C++14
+-----
+
+The features listed below are part of the C++14 standard. As a result, all
+these features are enabled with the ``-std=C++14`` or ``-std=gnu++14`` option
+when compiling C++ code.
+
+C++14 binary literals
+^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_binary_literals)`` or
+``__has_extension(cxx_binary_literals)`` to determine whether
+binary literals (for instance, ``0b10010``) are recognized. Clang supports this
+feature as an extension in all language modes.
+
+C++14 contextual conversions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_contextual_conversions)`` or
+``__has_extension(cxx_contextual_conversions)`` to determine if the C++14 rules
+are used when performing an implicit conversion for an array bound in a
+*new-expression*, the operand of a *delete-expression*, an integral constant
+expression, or a condition in a ``switch`` statement.
+
+C++14 decltype(auto)
+^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_decltype_auto)`` or
+``__has_extension(cxx_decltype_auto)`` to determine if support
+for the ``decltype(auto)`` placeholder type is enabled.
+
+C++14 default initializers for aggregates
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_aggregate_nsdmi)`` or
+``__has_extension(cxx_aggregate_nsdmi)`` to determine if support
+for default initializers in aggregate members is enabled.
+
+C++14 digit separators
+^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__cpp_digit_separators`` to determine if support for digit separators
+using single quotes (for instance, ``10'000``) is enabled. At this time, there
+is no corresponding ``__has_feature`` name
+
+C++14 generalized lambda capture
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_init_captures)`` or
+``__has_extension(cxx_init_captures)`` to determine if support for
+lambda captures with explicit initializers is enabled
+(for instance, ``[n(0)] { return ++n; }``).
+
+C++14 generic lambdas
+^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_generic_lambdas)`` or
+``__has_extension(cxx_generic_lambdas)`` to determine if support for generic
+(polymorphic) lambdas is enabled
+(for instance, ``[] (auto x) { return x + 1; }``).
+
+C++14 relaxed constexpr
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_relaxed_constexpr)`` or
+``__has_extension(cxx_relaxed_constexpr)`` to determine if variable
+declarations, local variable modification, and control flow constructs
+are permitted in ``constexpr`` functions.
+
+C++14 return type deduction
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_return_type_deduction)`` or
+``__has_extension(cxx_return_type_deduction)`` to determine if support
+for return type deduction for functions (using ``auto`` as a return type)
+is enabled.
+
+C++14 runtime-sized arrays
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_runtime_array)`` or
+``__has_extension(cxx_runtime_array)`` to determine if support
+for arrays of runtime bound (a restricted form of variable-length arrays)
+is enabled.
+Clang's implementation of this feature is incomplete.
+
+C++14 variable templates
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(cxx_variable_templates)`` or
+``__has_extension(cxx_variable_templates)`` to determine if support for
+templated variable declarations is enabled.
+
+C11
+---
+
+The features listed below are part of the C11 standard. As a result, all these
+features are enabled with the ``-std=c11`` or ``-std=gnu11`` option when
+compiling C code. Additionally, because these features are all
+backward-compatible, they are available as extensions in all language modes.
+
+C11 alignment specifiers
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(c_alignas)`` or ``__has_extension(c_alignas)`` to determine
+if support for alignment specifiers using ``_Alignas`` is enabled.
+
+Use ``__has_feature(c_alignof)`` or ``__has_extension(c_alignof)`` to determine
+if support for the ``_Alignof`` keyword is enabled.
+
+C11 atomic operations
+^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(c_atomic)`` or ``__has_extension(c_atomic)`` to determine
+if support for atomic types using ``_Atomic`` is enabled. Clang also provides
+:ref:`a set of builtins <langext-__c11_atomic>` which can be used to implement
+the ``<stdatomic.h>`` operations on ``_Atomic`` types. Use
+``__has_include(<stdatomic.h>)`` to determine if C11's ``<stdatomic.h>`` header
+is available.
+
+Clang will use the system's ``<stdatomic.h>`` header when one is available, and
+will otherwise use its own. When using its own, implementations of the atomic
+operations are provided as macros. In the cases where C11 also requires a real
+function, this header provides only the declaration of that function (along
+with a shadowing macro implementation), and you must link to a library which
+provides a definition of the function if you use it instead of the macro.
+
+C11 generic selections
+^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(c_generic_selections)`` or
+``__has_extension(c_generic_selections)`` to determine if support for generic
+selections is enabled.
+
+As an extension, the C11 generic selection expression is available in all
+languages supported by Clang. The syntax is the same as that given in the C11
+standard.
+
+In C, type compatibility is decided according to the rules given in the
+appropriate standard, but in C++, which lacks the type compatibility rules used
+in C, types are considered compatible only if they are equivalent.
+
+C11 ``_Static_assert()``
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(c_static_assert)`` or ``__has_extension(c_static_assert)``
+to determine if support for compile-time assertions using ``_Static_assert`` is
+enabled.
+
+C11 ``_Thread_local``
+^^^^^^^^^^^^^^^^^^^^^
+
+Use ``__has_feature(c_thread_local)`` or ``__has_extension(c_thread_local)``
+to determine if support for ``_Thread_local`` variables is enabled.
+
+Modules
+-------
+
+Use ``__has_feature(modules)`` to determine if Modules have been enabled.
+For example, compiling code with ``-fmodules`` enables the use of Modules.
+
+More information could be found `here <http://clang.llvm.org/docs/Modules.html>`_.
+
+Checks for Type Trait Primitives
+================================
+
+Type trait primitives are special builtin constant expressions that can be used
+by the standard C++ library to facilitate or simplify the implementation of
+user-facing type traits in the <type_traits> header.
+
+They are not intended to be used directly by user code because they are
+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
+`Microsoft Visual C++ Type traits
+<http://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:
+
+.. code-block:: c++
+
+ #if __has_extension(is_convertible_to)
+ template<typename From, typename To>
+ struct is_convertible_to {
+ static const bool value = __is_convertible_to(From, To);
+ };
+ #else
+ // Emulate type trait for compatibility with other compilers.
+ #endif
+
+The following type trait primitives are supported by Clang:
+
+* ``__has_nothrow_assign`` (GNU, Microsoft)
+* ``__has_nothrow_copy`` (GNU, Microsoft)
+* ``__has_nothrow_constructor`` (GNU, Microsoft)
+* ``__has_trivial_assign`` (GNU, Microsoft)
+* ``__has_trivial_copy`` (GNU, Microsoft)
+* ``__has_trivial_constructor`` (GNU, Microsoft)
+* ``__has_trivial_destructor`` (GNU, Microsoft)
+* ``__has_virtual_destructor`` (GNU, Microsoft)
+* ``__is_abstract`` (GNU, Microsoft)
+* ``__is_aggregate`` (GNU, Microsoft)
+* ``__is_base_of`` (GNU, Microsoft)
+* ``__is_class`` (GNU, Microsoft)
+* ``__is_convertible_to`` (Microsoft)
+* ``__is_empty`` (GNU, Microsoft)
+* ``__is_enum`` (GNU, Microsoft)
+* ``__is_interface_class`` (Microsoft)
+* ``__is_pod`` (GNU, Microsoft)
+* ``__is_polymorphic`` (GNU, Microsoft)
+* ``__is_union`` (GNU, Microsoft)
+* ``__is_literal(type)``: Determines whether the given type is a literal type
+* ``__is_final``: Determines whether the given type is declared with a
+ ``final`` class-virt-specifier.
+* ``__underlying_type(type)``: Retrieves the underlying type for a given
+ ``enum`` type. This trait is required to implement the C++11 standard
+ library.
+* ``__is_trivially_assignable(totype, fromtype)``: Determines whether a value
+ of type ``totype`` can be assigned to from a value of type ``fromtype`` such
+ that no non-trivial functions are called as part of that assignment. This
+ trait is required to implement the C++11 standard library.
+* ``__is_trivially_constructible(type, argtypes...)``: Determines whether a
+ value of type ``type`` can be direct-initialized with arguments of types
+ ``argtypes...`` such that no non-trivial functions are called as part of
+ that initialization. This trait is required to implement the C++11 standard
+ library.
+* ``__is_destructible`` (MSVC 2013)
+* ``__is_nothrow_destructible`` (MSVC 2013)
+* ``__is_nothrow_assignable`` (MSVC 2013, clang)
+* ``__is_constructible`` (MSVC 2013, clang)
+* ``__is_nothrow_constructible`` (MSVC 2013, clang)
+* ``__is_assignable`` (MSVC 2015, clang)
+
+Blocks
+======
+
+The syntax and high level language feature description is in
+:doc:`BlockLanguageSpec<BlockLanguageSpec>`. Implementation and ABI details for
+the clang implementation are in :doc:`Block-ABI-Apple<Block-ABI-Apple>`.
+
+Query for this feature with ``__has_extension(blocks)``.
+
+Objective-C Features
+====================
+
+Related result types
+--------------------
+
+According to Cocoa conventions, Objective-C methods with certain names
+("``init``", "``alloc``", etc.) always return objects that are an instance of
+the receiving class's type. Such methods are said to have a "related result
+type", meaning that a message send to one of these methods will have the same
+static type as an instance of the receiver class. For example, given the
+following classes:
+
+.. code-block:: objc
+
+ @interface NSObject
+ + (id)alloc;
+ - (id)init;
+ @end
+
+ @interface NSArray : NSObject
+ @end
+
+and this common initialization pattern
+
+.. code-block:: objc
+
+ NSArray *array = [[NSArray alloc] init];
+
+the type of the expression ``[NSArray alloc]`` is ``NSArray*`` because
+``alloc`` implicitly has a related result type. Similarly, the type of the
+expression ``[[NSArray alloc] init]`` is ``NSArray*``, since ``init`` has a
+related result type and its receiver is known to have the type ``NSArray *``.
+If neither ``alloc`` nor ``init`` had a related result type, the expressions
+would have had type ``id``, as declared in the method signature.
+
+A method with a related result type can be declared by using the type
+``instancetype`` as its result type. ``instancetype`` is a contextual keyword
+that is only permitted in the result type of an Objective-C method, e.g.
+
+.. code-block:: objc
+
+ @interface A
+ + (instancetype)constructAnA;
+ @end
+
+The related result type can also be inferred for some methods. To determine
+whether a method has an inferred related result type, the first word in the
+camel-case selector (e.g., "``init``" in "``initWithObjects``") is considered,
+and the method will have a related result type if its return type is compatible
+with the type of its class and if:
+
+* the first word is "``alloc``" or "``new``", and the method is a class method,
+ or
+
+* the first word is "``autorelease``", "``init``", "``retain``", or "``self``",
+ and the method is an instance method.
+
+If a method with a related result type is overridden by a subclass method, the
+subclass method must also return a type that is compatible with the subclass
+type. For example:
+
+.. code-block:: objc
+
+ @interface NSString : NSObject
+ - (NSUnrelated *)init; // incorrect usage: NSUnrelated is not NSString or a superclass of NSString
+ @end
+
+Related result types only affect the type of a message send or property access
+via the given method. In all other respects, a method with a related result
+type is treated the same way as method that returns ``id``.
+
+Use ``__has_feature(objc_instancetype)`` to determine whether the
+``instancetype`` contextual keyword is available.
+
+Automatic reference counting
+----------------------------
+
+Clang provides support for :doc:`automated reference counting
+<AutomaticReferenceCounting>` in Objective-C, which eliminates the need
+for manual ``retain``/``release``/``autorelease`` message sends. There are two
+feature macros associated with automatic reference counting:
+``__has_feature(objc_arc)`` indicates the availability of automated reference
+counting in general, while ``__has_feature(objc_arc_weak)`` indicates that
+automated reference counting also includes support for ``__weak`` pointers to
+Objective-C objects.
+
+.. _objc-fixed-enum:
+
+Enumerations with a fixed underlying type
+-----------------------------------------
+
+Clang provides support for C++11 enumerations with a fixed underlying type
+within Objective-C. For example, one can write an enumeration type as:
+
+.. code-block:: c++
+
+ typedef enum : unsigned char { Red, Green, Blue } Color;
+
+This specifies that the underlying type, which is used to store the enumeration
+value, is ``unsigned char``.
+
+Use ``__has_feature(objc_fixed_enum)`` to determine whether support for fixed
+underlying types is available in Objective-C.
+
+Interoperability with C++11 lambdas
+-----------------------------------
+
+Clang provides interoperability between C++11 lambdas and blocks-based APIs, by
+permitting a lambda to be implicitly converted to a block pointer with the
+corresponding signature. For example, consider an API such as ``NSArray``'s
+array-sorting method:
+
+.. code-block:: objc
+
+ - (NSArray *)sortedArrayUsingComparator:(NSComparator)cmptr;
+
+``NSComparator`` is simply a typedef for the block pointer ``NSComparisonResult
+(^)(id, id)``, and parameters of this type are generally provided with block
+literals as arguments. However, one can also use a C++11 lambda so long as it
+provides the same signature (in this case, accepting two parameters of type
+``id`` and returning an ``NSComparisonResult``):
+
+.. code-block:: objc
+
+ NSArray *array = @[@"string 1", @"string 21", @"string 12", @"String 11",
+ @"String 02"];
+ const NSStringCompareOptions comparisonOptions
+ = NSCaseInsensitiveSearch | NSNumericSearch |
+ NSWidthInsensitiveSearch | NSForcedOrderingSearch;
+ NSLocale *currentLocale = [NSLocale currentLocale];
+ NSArray *sorted
+ = [array sortedArrayUsingComparator:[=](id s1, id s2) -> NSComparisonResult {
+ NSRange string1Range = NSMakeRange(0, [s1 length]);
+ return [s1 compare:s2 options:comparisonOptions
+ range:string1Range locale:currentLocale];
+ }];
+ NSLog(@"sorted: %@", sorted);
+
+This code relies on an implicit conversion from the type of the lambda
+expression (an unnamed, local class type called the *closure type*) to the
+corresponding block pointer type. The conversion itself is expressed by a
+conversion operator in that closure type that produces a block pointer with the
+same signature as the lambda itself, e.g.,
+
+.. code-block:: objc
+
+ operator NSComparisonResult (^)(id, id)() const;
+
+This conversion function returns a new block that simply forwards the two
+parameters to the lambda object (which it captures by copy), then returns the
+result. The returned block is first copied (with ``Block_copy``) and then
+autoreleased. As an optimization, if a lambda expression is immediately
+converted to a block pointer (as in the first example, above), then the block
+is not copied and autoreleased: rather, it is given the same lifetime as a
+block literal written at that point in the program, which avoids the overhead
+of copying a block to the heap in the common case.
+
+The conversion from a lambda to a block pointer is only available in
+Objective-C++, and not in C++ with blocks, due to its use of Objective-C memory
+management (autorelease).
+
+Object Literals and Subscripting
+--------------------------------
+
+Clang provides support for :doc:`Object Literals and Subscripting
+<ObjectiveCLiterals>` in Objective-C, which simplifies common Objective-C
+programming patterns, makes programs more concise, and improves the safety of
+container creation. There are several feature macros associated with object
+literals and subscripting: ``__has_feature(objc_array_literals)`` tests the
+availability of array literals; ``__has_feature(objc_dictionary_literals)``
+tests the availability of dictionary literals;
+``__has_feature(objc_subscripting)`` tests the availability of object
+subscripting.
+
+Objective-C Autosynthesis of Properties
+---------------------------------------
+
+Clang provides support for autosynthesis of declared properties. Using this
+feature, clang provides default synthesis of those properties not declared
+ at dynamic and not having user provided backing getter and setter methods.
+``__has_feature(objc_default_synthesize_properties)`` checks for availability
+of this feature in version of clang being used.
+
+.. _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>`_
+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 <http://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
+``cf_returns_not_retained`` attributes can be placed on methods and functions
+that return Objective-C or CoreFoundation objects. They are commonly placed at
+the end of a function prototype or method declaration:
+
+.. code-block:: objc
+
+ id foo() __attribute__((ns_returns_retained));
+
+ - (NSString *)bar:(int)x __attribute__((ns_returns_retained));
+
+The ``*_returns_retained`` attributes specify that the returned object has a +1
+retain count. The ``*_returns_not_retained`` attributes specify that the return
+object has a +0 retain count, even if the normal convention for its selector
+would be +1. ``ns_returns_autoreleased`` specifies that the returned object is
++0, but is guaranteed to live at least as long as the next flush of an
+autorelease pool.
+
+**Usage**: The ``ns_consumed`` and ``cf_consumed`` attributes can be placed on
+an parameter declaration; they specify that the argument is expected to have a
++1 retain count, which will be balanced in some way by the function or method.
+The ``ns_consumes_self`` attribute can only be placed on an Objective-C
+method; it specifies that the method expects its ``self`` parameter to have a
++1 retain count, which it will balance in some way.
+
+.. code-block:: objc
+
+ void foo(__attribute__((ns_consumed)) NSString *string);
+
+ - (void) bar __attribute__((ns_consumes_self));
+ - (void) baz:(id) __attribute__((ns_consumed)) x;
+
+Further examples of these attributes are available in the static analyzer's `list of annotations for analysis
+<http://clang-analyzer.llvm.org/annotations.html#cocoa_mem>`_.
+
+Query for these features with ``__has_attribute(ns_consumed)``,
+``__has_attribute(ns_returns_retained)``, etc.
+
+Objective-C @available
+----------------------
+
+It is possible to use the newest SDK but still build a program that can run on
+older versions of macOS and iOS by passing ``-mmacosx-version-min=`` /
+``-miphoneos-version-min=``.
+
+Before LLVM 5.0, when calling a function that exists only in the OS that's
+newer than the target OS (as determined by the minimum deployment version),
+programmers had to carefully check if the function exists at runtime, using
+null checks for weakly-linked C functions, ``+class`` for Objective-C classes,
+and ``-respondsToSelector:`` or ``+instancesRespondToSelector:`` for
+Objective-C methods. If such a check was missed, the program would compile
+fine, run fine on newer systems, but crash on older systems.
+
+As of LLVM 5.0, ``-Wunguarded-availability`` uses the `availability attributes
+<http://clang.llvm.org/docs/AttributeReference.html#availability>`_ together
+with the new ``@available()`` keyword to assist with this issue.
+When a method that's introduced in the OS newer than the target OS is called, a
+-Wunguarded-availability warning is emitted if that call is not guarded:
+
+.. code-block:: objc
+
+ void my_fun(NSSomeClass* var) {
+ // If fancyNewMethod was added in e.g. macOS 10.12, but the code is
+ // built with -mmacosx-version-min=10.11, then this unconditional call
+ // will emit a -Wunguarded-availability warning:
+ [var fancyNewMethod];
+ }
+
+To fix the warning and to avoid the crash on macOS 10.11, wrap it in
+``if(@available())``:
+
+.. code-block:: objc
+
+ void my_fun(NSSomeClass* var) {
+ if (@available(macOS 10.12, *)) {
+ [var fancyNewMethod];
+ } else {
+ // Put fallback behavior for old macOS versions (and for non-mac
+ // platforms) here.
+ }
+ }
+
+The ``*`` is required and means that platforms not explicitly listed will take
+the true branch, and the compiler will emit ``-Wunguarded-availability``
+warnings for unlisted platforms based on those platform's deployment target.
+More than one platform can be listed in ``@available()``:
+
+.. code-block:: objc
+
+ void my_fun(NSSomeClass* var) {
+ if (@available(macOS 10.12, iOS 10, *)) {
+ [var fancyNewMethod];
+ }
+ }
+
+If the caller of ``my_fun()`` already checks that ``my_fun()`` is only called
+on 10.12, then add an `availability attribute
+<http://clang.llvm.org/docs/AttributeReference.html#availability>`_ to it,
+which will also suppress the warning and require that calls to my_fun() are
+checked:
+
+.. code-block:: objc
+
+ API_AVAILABLE(macos(10.12)) void my_fun(NSSomeClass* var) {
+ [var fancyNewMethod]; // Now ok.
+ }
+
+``@available()`` is only available in Objective-C code. To use the feature
+in C and C++ code, use the ``__builtin_available()`` spelling instead.
+
+If existing code uses null checks or ``-respondsToSelector:``, it should
+be changed to use ``@available()`` (or ``__builtin_available``) instead.
+
+``-Wunguarded-availability`` is disabled by default, but
+``-Wunguarded-availability-new``, which only emits this warning for APIs
+that have been introduced in macOS >= 10.13, iOS >= 11, watchOS >= 4 and
+tvOS >= 11, is enabled by default.
+
+.. _langext-overloading:
+
+Objective-C++ ABI: protocol-qualifier mangling of parameters
+------------------------------------------------------------
+
+Starting with LLVM 3.4, Clang produces a new mangling for parameters whose
+type is a qualified-``id`` (e.g., ``id<Foo>``). This mangling allows such
+parameters to be differentiated from those with the regular unqualified ``id``
+type.
+
+This was a non-backward compatible mangling change to the ABI. This change
+allows proper overloading, and also prevents mangling conflicts with template
+parameters of protocol-qualified type.
+
+Query the presence of this new mangling with
+``__has_feature(objc_protocol_qualifier_mangling)``.
+
+Initializer lists for complex numbers in C
+==========================================
+
+clang supports an extension which allows the following in C:
+
+.. code-block:: c++
+
+ #include <math.h>
+ #include <complex.h>
+ complex float x = { 1.0f, INFINITY }; // Init to (1, Inf)
+
+This construct is useful because there is no way to separately initialize the
+real and imaginary parts of a complex variable in standard C, given that clang
+does not support ``_Imaginary``. (Clang also supports the ``__real__`` and
+``__imag__`` extensions from gcc, which help in some cases, but are not usable
+in static initializers.)
+
+Note that this extension does not allow eliding the braces; the meaning of the
+following two lines is different:
+
+.. code-block:: c++
+
+ complex float x[] = { { 1.0f, 1.0f } }; // [0] = (1, 1)
+ complex float x[] = { 1.0f, 1.0f }; // [0] = (1, 0), [1] = (1, 0)
+
+This extension also works in C++ mode, as far as that goes, but does not apply
+to the C++ ``std::complex``. (In C++11, list initialization allows the same
+syntax to be used with ``std::complex`` with the same meaning.)
+
+Builtin Functions
+=================
+
+Clang supports a number of builtin library functions with the same syntax as
+GCC, including things like ``__builtin_nan``, ``__builtin_constant_p``,
+``__builtin_choose_expr``, ``__builtin_types_compatible_p``,
+``__builtin_assume_aligned``, ``__sync_fetch_and_add``, etc. In addition to
+the GCC builtins, Clang supports a number of builtins that GCC does not, which
+are listed here.
+
+Please note that Clang does not and will not support all of the GCC builtins
+for vector operations. Instead of using builtins, you should use the functions
+defined in target-specific header files like ``<xmmintrin.h>``, which define
+portable wrappers for these. Many of the Clang versions of these functions are
+implemented directly in terms of :ref:`extended vector support
+<langext-vectors>` instead of builtins, in order to reduce the number of
+builtins that we need to implement.
+
+``__builtin_assume``
+------------------------------
+
+``__builtin_assume`` is used to provide the optimizer with a boolean
+invariant that is defined to be true.
+
+**Syntax**:
+
+.. code-block:: c++
+
+ __builtin_assume(bool)
+
+**Example of Use**:
+
+.. code-block:: c++
+
+ int foo(int x) {
+ __builtin_assume(x != 0);
+
+ // The optimizer may short-circuit this check using the invariant.
+ if (x == 0)
+ return do_something();
+
+ return do_something_else();
+ }
+
+**Description**:
+
+The boolean argument to this function is defined to be true. The optimizer may
+analyze the form of the expression provided as the argument and deduce from
+that information used to optimize the program. If the condition is violated
+during execution, the behavior is undefined. The argument itself is never
+evaluated, so any side effects of the expression will be discarded.
+
+Query for this feature with ``__has_builtin(__builtin_assume)``.
+
+``__builtin_readcyclecounter``
+------------------------------
+
+``__builtin_readcyclecounter`` is used to access the cycle counter register (or
+a similar low-latency, high-accuracy clock) on those targets that support it.
+
+**Syntax**:
+
+.. code-block:: c++
+
+ __builtin_readcyclecounter()
+
+**Example of Use**:
+
+.. code-block:: c++
+
+ unsigned long long t0 = __builtin_readcyclecounter();
+ do_something();
+ unsigned long long t1 = __builtin_readcyclecounter();
+ unsigned long long cycles_to_do_something = t1 - t0; // assuming no overflow
+
+**Description**:
+
+The ``__builtin_readcyclecounter()`` builtin returns the cycle counter value,
+which may be either global or process/thread-specific depending on the target.
+As the backing counters often overflow quickly (on the order of seconds) this
+should only be used for timing small intervals. When not supported by the
+target, the return value is always zero. This builtin takes no arguments and
+produces an unsigned long long result.
+
+Query for this feature with ``__has_builtin(__builtin_readcyclecounter)``. Note
+that even if present, its use may depend on run-time privilege or other OS
+controlled state.
+
+.. _langext-__builtin_shufflevector:
+
+``__builtin_shufflevector``
+---------------------------
+
+``__builtin_shufflevector`` is used to express generic vector
+permutation/shuffle/swizzle operations. This builtin is also very important
+for the implementation of various target-specific header files like
+``<xmmintrin.h>``.
+
+**Syntax**:
+
+.. code-block:: c++
+
+ __builtin_shufflevector(vec1, vec2, index1, index2, ...)
+
+**Examples**:
+
+.. code-block:: c++
+
+ // identity operation - return 4-element vector v1.
+ __builtin_shufflevector(v1, v1, 0, 1, 2, 3)
+
+ // "Splat" element 0 of V1 into a 4-element result.
+ __builtin_shufflevector(V1, V1, 0, 0, 0, 0)
+
+ // Reverse 4-element vector V1.
+ __builtin_shufflevector(V1, V1, 3, 2, 1, 0)
+
+ // Concatenate every other element of 4-element vectors V1 and V2.
+ __builtin_shufflevector(V1, V2, 0, 2, 4, 6)
+
+ // Concatenate every other element of 8-element vectors V1 and V2.
+ __builtin_shufflevector(V1, V2, 0, 2, 4, 6, 8, 10, 12, 14)
+
+ // Shuffle v1 with some elements being undefined
+ __builtin_shufflevector(v1, v1, 3, -1, 1, -1)
+
+**Description**:
+
+The first two arguments to ``__builtin_shufflevector`` are vectors that have
+the same element type. The remaining arguments are a list of integers that
+specify the elements indices of the first two vectors that should be extracted
+and returned in a new vector. These element indices are numbered sequentially
+starting with the first vector, continuing into the second vector. Thus, if
+``vec1`` is a 4-element vector, index 5 would refer to the second element of
+``vec2``. An index of -1 can be used to indicate that the corresponding element
+in the returned vector is a don't care and can be optimized by the backend.
+
+The result of ``__builtin_shufflevector`` is a vector with the same element
+type as ``vec1``/``vec2`` but that has an element count equal to the number of
+indices specified.
+
+Query for this feature with ``__has_builtin(__builtin_shufflevector)``.
+
+.. _langext-__builtin_convertvector:
+
+``__builtin_convertvector``
+---------------------------
+
+``__builtin_convertvector`` is used to express generic vector
+type-conversion operations. The input vector and the output vector
+type must have the same number of elements.
+
+**Syntax**:
+
+.. code-block:: c++
+
+ __builtin_convertvector(src_vec, dst_vec_type)
+
+**Examples**:
+
+.. code-block:: c++
+
+ typedef double vector4double __attribute__((__vector_size__(32)));
+ typedef float vector4float __attribute__((__vector_size__(16)));
+ typedef short vector4short __attribute__((__vector_size__(8)));
+ vector4float vf; vector4short vs;
+
+ // convert from a vector of 4 floats to a vector of 4 doubles.
+ __builtin_convertvector(vf, vector4double)
+ // equivalent to:
+ (vector4double) { (double) vf[0], (double) vf[1], (double) vf[2], (double) vf[3] }
+
+ // convert from a vector of 4 shorts to a vector of 4 floats.
+ __builtin_convertvector(vs, vector4float)
+ // equivalent to:
+ (vector4float) { (float) vs[0], (float) vs[1], (float) vs[2], (float) vs[3] }
+
+**Description**:
+
+The first argument to ``__builtin_convertvector`` is a vector, and the second
+argument is a vector type with the same number of elements as the first
+argument.
+
+The result of ``__builtin_convertvector`` is a vector with the same element
+type as the second argument, with a value defined in terms of the action of a
+C-style cast applied to each element of the first argument.
+
+Query for this feature with ``__has_builtin(__builtin_convertvector)``.
+
+``__builtin_bitreverse``
+------------------------
+
+* ``__builtin_bitreverse8``
+* ``__builtin_bitreverse16``
+* ``__builtin_bitreverse32``
+* ``__builtin_bitreverse64``
+
+**Syntax**:
+
+.. code-block:: c++
+
+ __builtin_bitreverse32(x)
+
+**Examples**:
+
+.. code-block:: c++
+
+ uint8_t rev_x = __builtin_bitreverse8(x);
+ uint16_t rev_x = __builtin_bitreverse16(x);
+ uint32_t rev_y = __builtin_bitreverse32(y);
+ uint64_t rev_z = __builtin_bitreverse64(z);
+
+**Description**:
+
+The '``__builtin_bitreverse``' family of builtins is used to reverse
+the bitpattern of an integer value; for example ``0b10110110`` becomes
+``0b01101101``.
+
+``__builtin_unreachable``
+-------------------------
+
+``__builtin_unreachable`` is used to indicate that a specific point in the
+program cannot be reached, even if the compiler might otherwise think it can.
+This is useful to improve optimization and eliminates certain warnings. For
+example, without the ``__builtin_unreachable`` in the example below, the
+compiler assumes that the inline asm can fall through and prints a "function
+declared '``noreturn``' should not return" warning.
+
+**Syntax**:
+
+.. code-block:: c++
+
+ __builtin_unreachable()
+
+**Example of use**:
+
+.. code-block:: c++
+
+ void myabort(void) __attribute__((noreturn));
+ void myabort(void) {
+ asm("int3");
+ __builtin_unreachable();
+ }
+
+**Description**:
+
+The ``__builtin_unreachable()`` builtin has completely undefined behavior.
+Since it has undefined behavior, it is a statement that it is never reached and
+the optimizer can take advantage of this to produce better code. This builtin
+takes no arguments and produces a void result.
+
+Query for this feature with ``__has_builtin(__builtin_unreachable)``.
+
+``__builtin_unpredictable``
+---------------------------
+
+``__builtin_unpredictable`` is used to indicate that a branch condition is
+unpredictable by hardware mechanisms such as branch prediction logic.
+
+**Syntax**:
+
+.. code-block:: c++
+
+ __builtin_unpredictable(long long)
+
+**Example of use**:
+
+.. code-block:: c++
+
+ if (__builtin_unpredictable(x > 0)) {
+ foo();
+ }
+
+**Description**:
+
+The ``__builtin_unpredictable()`` builtin is expected to be used with control
+flow conditions such as in ``if`` and ``switch`` statements.
+
+Query for this feature with ``__has_builtin(__builtin_unpredictable)``.
+
+``__sync_swap``
+---------------
+
+``__sync_swap`` is used to atomically swap integers or pointers in memory.
+
+**Syntax**:
+
+.. code-block:: c++
+
+ type __sync_swap(type *ptr, type value, ...)
+
+**Example of Use**:
+
+.. code-block:: c++
+
+ int old_value = __sync_swap(&value, new_value);
+
+**Description**:
+
+The ``__sync_swap()`` builtin extends the existing ``__sync_*()`` family of
+atomic intrinsics to allow code to atomically swap the current value with the
+new value. More importantly, it helps developers write more efficient and
+correct code by avoiding expensive loops around
+``__sync_bool_compare_and_swap()`` or relying on the platform specific
+implementation details of ``__sync_lock_test_and_set()``. The
+``__sync_swap()`` builtin is a full barrier.
+
+``__builtin_addressof``
+-----------------------
+
+``__builtin_addressof`` performs the functionality of the built-in ``&``
+operator, ignoring any ``operator&`` overload. This is useful in constant
+expressions in C++11, where there is no other way to take the address of an
+object that overloads ``operator&``.
+
+**Example of use**:
+
+.. code-block:: c++
+
+ template<typename T> constexpr T *addressof(T &value) {
+ return __builtin_addressof(value);
+ }
+
+``__builtin_operator_new`` and ``__builtin_operator_delete``
+------------------------------------------------------------
+
+``__builtin_operator_new`` allocates memory just like a non-placement non-class
+*new-expression*. This is exactly like directly calling the normal
+non-placement ``::operator new``, except that it allows certain optimizations
+that the C++ standard does not permit for a direct function call to
+``::operator new`` (in particular, removing ``new`` / ``delete`` pairs and
+merging allocations).
+
+Likewise, ``__builtin_operator_delete`` deallocates memory just like a
+non-class *delete-expression*, and is exactly like directly calling the normal
+``::operator delete``, except that it permits optimizations. Only the unsized
+form of ``__builtin_operator_delete`` is currently available.
+
+These builtins are intended for use in the implementation of ``std::allocator``
+and other similar allocation libraries, and are only available in C++.
+
+Multiprecision Arithmetic Builtins
+----------------------------------
+
+Clang provides a set of builtins which expose multiprecision arithmetic in a
+manner amenable to C. They all have the following form:
+
+.. code-block:: c
+
+ unsigned x = ..., y = ..., carryin = ..., carryout;
+ unsigned sum = __builtin_addc(x, y, carryin, &carryout);
+
+Thus one can form a multiprecision addition chain in the following manner:
+
+.. code-block:: c
+
+ unsigned *x, *y, *z, carryin=0, carryout;
+ z[0] = __builtin_addc(x[0], y[0], carryin, &carryout);
+ carryin = carryout;
+ z[1] = __builtin_addc(x[1], y[1], carryin, &carryout);
+ carryin = carryout;
+ z[2] = __builtin_addc(x[2], y[2], carryin, &carryout);
+ carryin = carryout;
+ z[3] = __builtin_addc(x[3], y[3], carryin, &carryout);
+
+The complete list of builtins are:
+
+.. code-block:: c
+
+ unsigned char __builtin_addcb (unsigned char x, unsigned char y, unsigned char carryin, unsigned char *carryout);
+ unsigned short __builtin_addcs (unsigned short x, unsigned short y, unsigned short carryin, unsigned short *carryout);
+ unsigned __builtin_addc (unsigned x, unsigned y, unsigned carryin, unsigned *carryout);
+ unsigned long __builtin_addcl (unsigned long x, unsigned long y, unsigned long carryin, unsigned long *carryout);
+ unsigned long long __builtin_addcll(unsigned long long x, unsigned long long y, unsigned long long carryin, unsigned long long *carryout);
+ unsigned char __builtin_subcb (unsigned char x, unsigned char y, unsigned char carryin, unsigned char *carryout);
+ unsigned short __builtin_subcs (unsigned short x, unsigned short y, unsigned short carryin, unsigned short *carryout);
+ unsigned __builtin_subc (unsigned x, unsigned y, unsigned carryin, unsigned *carryout);
+ unsigned long __builtin_subcl (unsigned long x, unsigned long y, unsigned long carryin, unsigned long *carryout);
+ unsigned long long __builtin_subcll(unsigned long long x, unsigned long long y, unsigned long long carryin, unsigned long long *carryout);
+
+Checked Arithmetic Builtins
+---------------------------
+
+Clang provides a set of builtins that implement checked arithmetic for security
+critical applications in a manner that is fast and easily expressable in C. As
+an example of their usage:
+
+.. code-block:: c
+
+ errorcode_t security_critical_application(...) {
+ unsigned x, y, result;
+ ...
+ if (__builtin_mul_overflow(x, y, &result))
+ return kErrorCodeHackers;
+ ...
+ use_multiply(result);
+ ...
+ }
+
+Clang provides the following checked arithmetic builtins:
+
+.. code-block:: c
+
+ bool __builtin_add_overflow (type1 x, type2 y, type3 *sum);
+ bool __builtin_sub_overflow (type1 x, type2 y, type3 *diff);
+ bool __builtin_mul_overflow (type1 x, type2 y, type3 *prod);
+ bool __builtin_uadd_overflow (unsigned x, unsigned y, unsigned *sum);
+ bool __builtin_uaddl_overflow (unsigned long x, unsigned long y, unsigned long *sum);
+ bool __builtin_uaddll_overflow(unsigned long long x, unsigned long long y, unsigned long long *sum);
+ bool __builtin_usub_overflow (unsigned x, unsigned y, unsigned *diff);
+ bool __builtin_usubl_overflow (unsigned long x, unsigned long y, unsigned long *diff);
+ bool __builtin_usubll_overflow(unsigned long long x, unsigned long long y, unsigned long long *diff);
+ bool __builtin_umul_overflow (unsigned x, unsigned y, unsigned *prod);
+ bool __builtin_umull_overflow (unsigned long x, unsigned long y, unsigned long *prod);
+ bool __builtin_umulll_overflow(unsigned long long x, unsigned long long y, unsigned long long *prod);
+ bool __builtin_sadd_overflow (int x, int y, int *sum);
+ bool __builtin_saddl_overflow (long x, long y, long *sum);
+ bool __builtin_saddll_overflow(long long x, long long y, long long *sum);
+ bool __builtin_ssub_overflow (int x, int y, int *diff);
+ bool __builtin_ssubl_overflow (long x, long y, long *diff);
+ bool __builtin_ssubll_overflow(long long x, long long y, long long *diff);
+ bool __builtin_smul_overflow (int x, int y, int *prod);
+ bool __builtin_smull_overflow (long x, long y, long *prod);
+ bool __builtin_smulll_overflow(long long x, long long y, long long *prod);
+
+Each builtin performs the specified mathematical operation on the
+first two arguments and stores the result in the third argument. If
+possible, the result will be equal to mathematically-correct result
+and the builtin will return 0. Otherwise, the builtin will return
+1 and the result will be equal to the unique value that is equivalent
+to the mathematically-correct result modulo two raised to the *k*
+power, where *k* is the number of bits in the result type. The
+behavior of these builtins is well-defined for all argument values.
+
+The first three builtins work generically for operands of any integer type,
+including boolean types. The operands need not have the same type as each
+other, or as the result. The other builtins may implicitly promote or
+convert their operands before performing the operation.
+
+Query for this feature with ``__has_builtin(__builtin_add_overflow)``, etc.
+
+Floating point builtins
+---------------------------------------
+
+``__builtin_canonicalize``
+--------------------------
+
+.. code-block:: c
+
+ double __builtin_canonicalize(double);
+ float __builtin_canonicalizef(float);
+ long double__builtin_canonicalizel(long double);
+
+Returns the platform specific canonical encoding of a floating point
+number. This canonicalization is useful for implementing certain
+numeric primitives such as frexp. See `LLVM canonicalize intrinsic
+<http://llvm.org/docs/LangRef.html#llvm-canonicalize-intrinsic>`_ for
+more information on the semantics.
+
+String builtins
+---------------
+
+Clang provides constant expression evaluation support for builtins forms of
+the following functions from the C standard library ``<string.h>`` header:
+
+* ``memchr``
+* ``memcmp``
+* ``strchr``
+* ``strcmp``
+* ``strlen``
+* ``strncmp``
+* ``wcschr``
+* ``wcscmp``
+* ``wcslen``
+* ``wcsncmp``
+* ``wmemchr``
+* ``wmemcmp``
+
+In each case, the builtin form has the name of the C library function prefixed
+by ``__builtin_``. Example:
+
+.. code-block:: c
+
+ void *p = __builtin_memchr("foobar", 'b', 5);
+
+In addition to the above, one further builtin is provided:
+
+.. code-block:: c
+
+ char *__builtin_char_memchr(const char *haystack, int needle, size_t size);
+
+``__builtin_char_memchr(a, b, c)`` is identical to
+``(char*)__builtin_memchr(a, b, c)`` except that its use is permitted within
+constant expressions in C++11 onwards (where a cast from ``void*`` to ``char*``
+is disallowed in general).
+
+Support for constant expression evaluation for the above builtins be detected
+with ``__has_feature(cxx_constexpr_string_builtins)``.
+
+.. _langext-__c11_atomic:
+
+__c11_atomic builtins
+---------------------
+
+Clang provides a set of builtins which are intended to be used to implement
+C11's ``<stdatomic.h>`` header. These builtins provide the semantics of the
+``_explicit`` form of the corresponding C11 operation, and are named with a
+``__c11_`` prefix. The supported operations, and the differences from
+the corresponding C11 operations, are:
+
+* ``__c11_atomic_init``
+* ``__c11_atomic_thread_fence``
+* ``__c11_atomic_signal_fence``
+* ``__c11_atomic_is_lock_free`` (The argument is the size of the
+ ``_Atomic(...)`` object, instead of its address)
+* ``__c11_atomic_store``
+* ``__c11_atomic_load``
+* ``__c11_atomic_exchange``
+* ``__c11_atomic_compare_exchange_strong``
+* ``__c11_atomic_compare_exchange_weak``
+* ``__c11_atomic_fetch_add``
+* ``__c11_atomic_fetch_sub``
+* ``__c11_atomic_fetch_and``
+* ``__c11_atomic_fetch_or``
+* ``__c11_atomic_fetch_xor``
+
+The macros ``__ATOMIC_RELAXED``, ``__ATOMIC_CONSUME``, ``__ATOMIC_ACQUIRE``,
+``__ATOMIC_RELEASE``, ``__ATOMIC_ACQ_REL``, and ``__ATOMIC_SEQ_CST`` are
+provided, with values corresponding to the enumerators of C11's
+``memory_order`` enumeration.
+
+(Note that Clang additionally provides GCC-compatible ``__atomic_*``
+builtins)
+
+Low-level ARM exclusive memory builtins
+---------------------------------------
+
+Clang provides overloaded builtins giving direct access to the three key ARM
+instructions for implementing atomic operations.
+
+.. code-block:: c
+
+ T __builtin_arm_ldrex(const volatile T *addr);
+ T __builtin_arm_ldaex(const volatile T *addr);
+ int __builtin_arm_strex(T val, volatile T *addr);
+ int __builtin_arm_stlex(T val, volatile T *addr);
+ void __builtin_arm_clrex(void);
+
+The types ``T`` currently supported are:
+
+* Integer types with width at most 64 bits (or 128 bits on AArch64).
+* Floating-point types
+* Pointer types.
+
+Note that the compiler does not guarantee it will not insert stores which clear
+the exclusive monitor in between an ``ldrex`` type operation and its paired
+``strex``. In practice this is only usually a risk when the extra store is on
+the same cache line as the variable being modified and Clang will only insert
+stack stores on its own, so it is best not to use these operations on variables
+with automatic storage duration.
+
+Also, loads and stores may be implicit in code written between the ``ldrex`` and
+``strex``. Clang will not necessarily mitigate the effects of these either, so
+care should be exercised.
+
+For these reasons the higher level atomic primitives should be preferred where
+possible.
+
+Non-temporal load/store builtins
+--------------------------------
+
+Clang provides overloaded builtins allowing generation of non-temporal memory
+accesses.
+
+.. code-block:: c
+
+ T __builtin_nontemporal_load(T *addr);
+ void __builtin_nontemporal_store(T value, T *addr);
+
+The types ``T`` currently supported are:
+
+* Integer types.
+* Floating-point types.
+* Vector types.
+
+Note that the compiler does not guarantee that non-temporal loads or stores
+will be used.
+
+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
+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);
+ bool __builtin_coro_done(void *addr);
+ void *__builtin_coro_promise(void *addr, int alignment, bool from_promise)
+
+**Example of use**:
+
+.. code-block:: c++
+
+ template <> struct coroutine_handle<void> {
+ void resume() const { __builtin_coro_resume(ptr); }
+ void destroy() const { __builtin_coro_destroy(ptr); }
+ bool done() const { return __builtin_coro_done(ptr); }
+ // ...
+ protected:
+ void *ptr;
+ };
+
+ template <typename Promise> struct coroutine_handle : coroutine_handle<> {
+ // ...
+ Promise &promise() const {
+ return *reinterpret_cast<Promise *>(
+ __builtin_coro_promise(ptr, alignof(Promise), /*from-promise=*/false));
+ }
+ static coroutine_handle from_promise(Promise &promise) {
+ coroutine_handle p;
+ p.ptr = __builtin_coro_promise(&promise, alignof(Promise),
+ /*from-promise=*/true);
+ return p;
+ }
+ };
+
+
+Other coroutine builtins are either for internal clang use or for use during
+development of the coroutine feature. See `Coroutines in LLVM
+<http://llvm.org/docs/Coroutines.html#intrinsics>`_ for
+more information on their semantics. Note that builtins matching the intrinsics
+that take token as the first parameter (llvm.coro.begin, llvm.coro.alloc,
+llvm.coro.free and llvm.coro.suspend) omit the token parameter and fill it to
+an appropriate value during the emission.
+
+**Syntax**:
+
+.. code-block:: c
+
+ size_t __builtin_coro_size()
+ void *__builtin_coro_frame()
+ void *__builtin_coro_free(void *coro_frame)
+
+ void *__builtin_coro_id(int align, void *promise, void *fnaddr, void *parts)
+ bool __builtin_coro_alloc()
+ void *__builtin_coro_begin(void *memory)
+ void __builtin_coro_end(void *coro_frame, bool unwind)
+ char __builtin_coro_suspend(bool final)
+ bool __builtin_coro_param(void *original, void *copy)
+
+Note that there is no builtin matching the `llvm.coro.save` intrinsic. LLVM
+automatically will insert one if the first argument to `llvm.coro.suspend` is
+token `none`. If a user calls `__builin_suspend`, clang will insert `token none`
+as the first argument to the intrinsic.
+
+Non-standard C++11 Attributes
+=============================
+
+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
+`GCC type attributes
+<http://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++
+
+ [[gnu::unused]] int a, f [[gnu::noreturn]] ();
+
+Target-Specific Extensions
+==========================
+
+Clang supports some language features conditionally on some targets.
+
+ARM/AArch64 Language Extensions
+-------------------------------
+
+Memory Barrier Intrinsics
+^^^^^^^^^^^^^^^^^^^^^^^^^
+Clang implements the ``__dmb``, ``__dsb`` and ``__isb`` intrinsics as defined
+in the `ARM C Language Extensions Release 2.0
+<http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf>`_.
+Note that these intrinsics are implemented as motion barriers that block
+reordering of memory accesses and side effect instructions. Other instructions
+like simple arithmetic may be reordered around the intrinsic. If you expect to
+have no reordering at all, use inline assembly instead.
+
+X86/X86-64 Language Extensions
+------------------------------
+
+The X86 backend has these language extensions:
+
+Memory references to specified segments
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Annotating a pointer with address space #256 causes it to be code generated
+relative to the X86 GS segment register, address space #257 causes it to be
+relative to the X86 FS segment, and address space #258 causes it to be
+relative to the X86 SS segment. Note that this is a very very low-level
+feature that should only be used if you know what you're doing (for example in
+an OS kernel).
+
+Here is an example:
+
+.. code-block:: c++
+
+ #define GS_RELATIVE __attribute__((address_space(256)))
+ int foo(int GS_RELATIVE *P) {
+ return *P;
+ }
+
+Which compiles to (on X86-32):
+
+.. code-block:: gas
+
+ _foo:
+ movl 4(%esp), %eax
+ movl %gs:(%eax), %eax
+ ret
+
+Extensions for Static Analysis
+==============================
+
+Clang supports additional attributes that are useful for documenting program
+invariants and rules for static analysis tools, such as the `Clang Static
+Analyzer <http://clang-analyzer.llvm.org/>`_. These attributes are documented
+in the analyzer's `list of source-level annotations
+<http://clang-analyzer.llvm.org/annotations.html>`_.
+
+
+Extensions for Dynamic Analysis
+===============================
+
+Use ``__has_feature(address_sanitizer)`` to check if the code is being built
+with :doc:`AddressSanitizer`.
+
+Use ``__has_feature(thread_sanitizer)`` to check if the code is being built
+with :doc:`ThreadSanitizer`.
+
+Use ``__has_feature(memory_sanitizer)`` to check if the code is being built
+with :doc:`MemorySanitizer`.
+
+Use ``__has_feature(safe_stack)`` to check if the code is being built
+with :doc:`SafeStack`.
+
+
+Extensions for selectively disabling optimization
+=================================================
+
+Clang provides a mechanism for selectively disabling optimizations in functions
+and methods.
+
+To disable optimizations in a single function definition, the GNU-style or C++11
+non-standard attribute ``optnone`` can be used.
+
+.. code-block:: c++
+
+ // The following functions will not be optimized.
+ // GNU-style attribute
+ __attribute__((optnone)) int foo() {
+ // ... code
+ }
+ // C++11 attribute
+ [[clang::optnone]] int bar() {
+ // ... code
+ }
+
+To facilitate disabling optimization for a range of function definitions, a
+range-based pragma is provided. Its syntax is ``#pragma clang optimize``
+followed by ``off`` or ``on``.
+
+All function definitions in the region between an ``off`` and the following
+``on`` will be decorated with the ``optnone`` attribute unless doing so would
+conflict with explicit attributes already present on the function (e.g. the
+ones that control inlining).
+
+.. code-block:: c++
+
+ #pragma clang optimize off
+ // This function will be decorated with optnone.
+ int foo() {
+ // ... code
+ }
+
+ // optnone conflicts with always_inline, so bar() will not be decorated.
+ __attribute__((always_inline)) int bar() {
+ // ... code
+ }
+ #pragma clang optimize on
+
+If no ``on`` is found to close an ``off`` region, the end of the region is the
+end of the compilation unit.
+
+Note that a stray ``#pragma clang optimize on`` does not selectively enable
+additional optimizations when compiling at low optimization levels. This feature
+can only be used to selectively disable optimizations.
+
+The pragma has an effect on functions only at the point of their definition; for
+function templates, this means that the state of the pragma at the point of an
+instantiation is not necessarily relevant. Consider the following example:
+
+.. code-block:: c++
+
+ template<typename T> T twice(T t) {
+ return 2 * t;
+ }
+
+ #pragma clang optimize off
+ template<typename T> T thrice(T t) {
+ return 3 * t;
+ }
+
+ int container(int a, int b) {
+ return twice(a) + thrice(b);
+ }
+ #pragma clang optimize on
+
+In this example, the definition of the template function ``twice`` is outside
+the pragma region, whereas the definition of ``thrice`` is inside the region.
+The ``container`` function is also in the region and will not be optimized, but
+it causes the instantiation of ``twice`` and ``thrice`` with an ``int`` type; of
+these two instantiations, ``twice`` will be optimized (because its definition
+was outside the region) and ``thrice`` will not be optimized.
+
+Extensions for loop hint optimizations
+======================================
+
+The ``#pragma clang loop`` directive is used to specify hints for optimizing the
+subsequent for, while, do-while, or c++11 range-based for loop. The directive
+provides options for vectorization, interleaving, unrolling and
+distribution. Loop hints can be specified before any loop and will be ignored if
+the optimization is not safe to apply.
+
+Vectorization and Interleaving
+------------------------------
+
+A vectorized loop performs multiple iterations of the original loop
+in parallel using vector instructions. The instruction set of the target
+processor determines which vector instructions are available and their vector
+widths. This restricts the types of loops that can be vectorized. The vectorizer
+automatically determines if the loop is safe and profitable to vectorize. A
+vector instruction cost model is used to select the vector width.
+
+Interleaving multiple loop iterations allows modern processors to further
+improve instruction-level parallelism (ILP) using advanced hardware features,
+such as multiple execution units and out-of-order execution. The vectorizer uses
+a cost model that depends on the register pressure and generated code size to
+select the interleaving count.
+
+Vectorization is enabled by ``vectorize(enable)`` and interleaving is enabled
+by ``interleave(enable)``. This is useful when compiling with ``-Os`` to
+manually enable vectorization or interleaving.
+
+.. code-block:: c++
+
+ #pragma clang loop vectorize(enable)
+ #pragma clang loop interleave(enable)
+ for(...) {
+ ...
+ }
+
+The vector width is specified by ``vectorize_width(_value_)`` and the interleave
+count is specified by ``interleave_count(_value_)``, where
+_value_ is a positive integer. This is useful for specifying the optimal
+width/count of the set of target architectures supported by your application.
+
+.. code-block:: c++
+
+ #pragma clang loop vectorize_width(2)
+ #pragma clang loop interleave_count(2)
+ for(...) {
+ ...
+ }
+
+Specifying a width/count of 1 disables the optimization, and is equivalent to
+``vectorize(disable)`` or ``interleave(disable)``.
+
+Loop Unrolling
+--------------
+
+Unrolling a loop reduces the loop control overhead and exposes more
+opportunities for ILP. Loops can be fully or partially unrolled. Full unrolling
+eliminates the loop and replaces it with an enumerated sequence of loop
+iterations. Full unrolling is only possible if the loop trip count is known at
+compile time. Partial unrolling replicates the loop body within the loop and
+reduces the trip count.
+
+If ``unroll(enable)`` is specified the unroller will attempt to fully unroll the
+loop if the trip count is known at compile time. If the fully unrolled code size
+is greater than an internal limit the loop will be partially unrolled up to this
+limit. If the trip count is not known at compile time the loop will be partially
+unrolled with a heuristically chosen unroll factor.
+
+.. code-block:: c++
+
+ #pragma clang loop unroll(enable)
+ for(...) {
+ ...
+ }
+
+If ``unroll(full)`` is specified the unroller will attempt to fully unroll the
+loop if the trip count is known at compile time identically to
+``unroll(enable)``. However, with ``unroll(full)`` the loop will not be unrolled
+if the loop count is not known at compile time.
+
+.. code-block:: c++
+
+ #pragma clang loop unroll(full)
+ for(...) {
+ ...
+ }
+
+The unroll count can be specified explicitly with ``unroll_count(_value_)`` where
+_value_ is a positive integer. If this value is greater than the trip count the
+loop will be fully unrolled. Otherwise the loop is partially unrolled subject
+to the same code size limit as with ``unroll(enable)``.
+
+.. code-block:: c++
+
+ #pragma clang loop unroll_count(8)
+ for(...) {
+ ...
+ }
+
+Unrolling of a loop can be prevented by specifying ``unroll(disable)``.
+
+Loop Distribution
+-----------------
+
+Loop Distribution allows splitting a loop into multiple loops. This is
+beneficial for example when the entire loop cannot be vectorized but some of the
+resulting loops can.
+
+If ``distribute(enable))`` is specified and the loop has memory dependencies
+that inhibit vectorization, the compiler will attempt to isolate the offending
+operations into a new loop. This optimization is not enabled by default, only
+loops marked with the pragma are considered.
+
+.. code-block:: c++
+
+ #pragma clang loop distribute(enable)
+ for (i = 0; i < N; ++i) {
+ S1: A[i + 1] = A[i] + B[i];
+ S2: C[i] = D[i] * E[i];
+ }
+
+This loop will be split into two loops between statements S1 and S2. The
+second loop containing S2 will be vectorized.
+
+Loop Distribution is currently not enabled by default in the optimizer because
+it can hurt performance in some cases. For example, instruction-level
+parallelism could be reduced by sequentializing the execution of the
+statements S1 and S2 above.
+
+If Loop Distribution is turned on globally with
+``-mllvm -enable-loop-distribution``, specifying ``distribute(disable)`` can
+be used the disable it on a per-loop basis.
+
+Additional Information
+----------------------
+
+For convenience multiple loop hints can be specified on a single line.
+
+.. code-block:: c++
+
+ #pragma clang loop vectorize_width(4) interleave_count(8)
+ for(...) {
+ ...
+ }
+
+If an optimization cannot be applied any hints that apply to it will be ignored.
+For example, the hint ``vectorize_width(4)`` is ignored if the loop is not
+proven safe to vectorize. To identify and diagnose optimization issues use
+`-Rpass`, `-Rpass-missed`, and `-Rpass-analysis` command line options. See the
+user guide for details.
+
+Extensions to specify floating-point flags
+====================================================
+
+The ``#pragma clang fp`` pragma allows floating-point options to be specified
+for a section of the source code. This pragma can only appear at file scope or
+at the start of a compound statement (excluding comments). When using within a
+compound statement, the pragma is active within the scope of the compound
+statement.
+
+Currently, only FP contraction can be controlled with the pragma. ``#pragma
+clang fp contract`` specifies whether the compiler should contract a multiply
+and an addition (or subtraction) into a fused FMA operation when supported by
+the target.
+
+The pragma can take three values: ``on``, ``fast`` and ``off``. The ``on``
+option is identical to using ``#pragma STDC FP_CONTRACT(ON)`` and it allows
+fusion as specified the language standard. The ``fast`` option allows fusiong
+in cases when the language standard does not make this possible (e.g. across
+statements in C)
+
+.. code-block:: c++
+
+ for(...) {
+ #pragma clang fp contract(fast)
+ a = b[i] * c[i];
+ d[i] += a;
+ }
+
+
+The pragma can also be used with ``off`` which turns FP contraction off for a
+section of the code. This can be useful when fast contraction is otherwise
+enabled for the translation unit with the ``-ffp-contract=fast`` flag.
+
+Specifying an attribute for multiple declarations (#pragma clang attribute)
+===========================================================================
+
+The ``#pragma clang attribute`` directive can be used to apply an attribute to
+multiple declarations. The ``#pragma clang attribute push`` variation of the
+directive pushes a new attribute to the attribute stack. The declarations that
+follow the pragma receive the attributes that are on the attribute stack, until
+the stack is cleared using a ``#pragma clang attribute pop`` directive. Multiple
+push directives can be nested inside each other.
+
+The attributes that are used in the ``#pragma clang attribute`` directives
+can be written using the GNU-style syntax:
+
+.. code-block:: c++
+
+ #pragma clang attribute push(__attribute__((annotate("custom"))), apply_to = function)
+
+ void function(); // The function now has the annotate("custom") attribute
+
+ #pragma clang attribute pop
+
+The attributes can also be written using the C++11 style syntax:
+
+.. code-block:: c++
+
+ #pragma clang attribute push([[noreturn]], apply_to = function)
+
+ void function(); // The function now has the [[noreturn]] attribute
+
+ #pragma clang attribute pop
+
+The ``__declspec`` style syntax is also supported:
+
+.. code-block:: c++
+
+ #pragma clang attribute push(__declspec(dllexport), apply_to = function)
+
+ void function(); // The function now has the __declspec(dllexport) attribute
+
+ #pragma clang attribute pop
+
+A single push directive accepts only one attribute regardless of the syntax
+used.
+
+Subject Match Rules
+-------------------
+
+The set of declarations that receive a single attribute from the attribute stack
+depends on the subject match rules that were specified in the pragma. Subject
+match rules are specified after the attribute. The compiler expects an
+identifier that corresponds to the subject set specifier. The ``apply_to``
+specifier is currently the only supported subject set specifier. It allows you
+to specify match rules that form a subset of the attribute's allowed subject
+set, i.e. the compiler doesn't require all of the attribute's subjects. For
+example, an attribute like ``[[nodiscard]]`` whose subject set includes
+``enum``, ``record`` and ``hasType(functionType)``, requires the presence of at
+least one of these rules after ``apply_to``:
+
+.. code-block:: c++
+
+ #pragma clang attribute push([[nodiscard]], apply_to = enum)
+
+ enum Enum1 { A1, B1 }; // The enum will receive [[nodiscard]]
+
+ struct Record1 { }; // The struct will *not* receive [[nodiscard]]
+
+ #pragma clang attribute pop
+
+ #pragma clang attribute push([[nodiscard]], apply_to = any(record, enum))
+
+ enum Enum2 { A2, B2 }; // The enum will receive [[nodiscard]]
+
+ struct Record2 { }; // The struct *will* receive [[nodiscard]]
+
+ #pragma clang attribute pop
+
+ // This is an error, since [[nodiscard]] can't be applied to namespaces:
+ #pragma clang attribute push([[nodiscard]], apply_to = any(record, namespace))
+
+ #pragma clang attribute pop
+
+Multiple match rules can be specified using the ``any`` match rule, as shown
+in the example above. The ``any`` rule applies attributes to all declarations
+that are matched by at least one of the rules in the ``any``. It doesn't nest
+and can't be used inside the other match rules. Redundant match rules or rules
+that conflict with one another should not be used inside of ``any``.
+
+Clang supports the following match rules:
+
+- ``function``: Can be used to apply attributes to functions. This includes C++
+ member functions, static functions, operators, and constructors/destructors.
+
+- ``function(is_member)``: Can be used to apply attributes to C++ member
+ functions. This includes members like static functions, operators, and
+ constructors/destructors.
+
+- ``hasType(functionType)``: Can be used to apply attributes to functions, C++
+ member functions, and variables/fields whose type is a function pointer. It
+ does not apply attributes to Objective-C methods or blocks.
+
+- ``type_alias``: Can be used to apply attributes to ``typedef`` declarations
+ and C++11 type aliases.
+
+- ``record``: Can be used to apply attributes to ``struct``, ``class``, and
+ ``union`` declarations.
+
+- ``record(unless(is_union))``: Can be used to apply attributes only to
+ ``struct`` and ``class`` declarations.
+
+- ``enum``: Can be be used to apply attributes to enumeration declarations.
+
+- ``enum_constant``: Can be used to apply attributes to enumerators.
+
+- ``variable``: Can be used to apply attributes to variables, including
+ local variables, parameters, global variables, and static member variables.
+ It does not apply attributes to instance member variables or Objective-C
+ ivars.
+
+- ``variable(is_thread_local)``: Can be used to apply attributes to thread-local
+ variables only.
+
+- ``variable(is_global)``: Can be used to apply attributes to global variables
+ only.
+
+- ``variable(is_parameter)``: Can be used to apply attributes to parameters
+ only.
+
+- ``variable(unless(is_parameter))``: Can be used to apply attributes to all
+ the variables that are not parameters.
+
+- ``field``: Can be used to apply attributes to non-static member variables
+ in a record. This includes Objective-C ivars.
+
+- ``namespace``: Can be used to apply attributes to ``namespace`` declarations.
+
+- ``objc_interface``: Can be used to apply attributes to ``@interface``
+ declarations.
+
+- ``objc_protocol``: Can be used to apply attributes to ``@protocol``
+ declarations.
+
+- ``objc_category``: Can be used to apply attributes to category declarations,
+ including class extensions.
+
+- ``objc_method``: Can be used to apply attributes to Objective-C methods,
+ including instance and class methods. Implicit methods like implicit property
+ getters and setters do not receive the attribute.
+
+- ``objc_method(is_instance)``: Can be used to apply attributes to Objective-C
+ instance methods.
+
+- ``objc_property``: Can be used to apply attributes to ``@property``
+ declarations.
+
+- ``block``: Can be used to apply attributes to block declarations. This does
+ not include variables/fields of block pointer type.
+
+The use of ``unless`` in match rules is currently restricted to a strict set of
+sub-rules that are used by the supported attributes. That means that even though
+``variable(unless(is_parameter))`` is a valid match rule,
+``variable(unless(is_thread_local))`` is not.
+
+Supported Attributes
+--------------------
+
+Not all attributes can be used with the ``#pragma clang attribute`` directive.
+Notably, statement attributes like ``[[fallthrough]]`` or type attributes
+like ``address_space`` aren't supported by this directive. You can determine
+whether or not an attribute is supported by the pragma by referring to the
+:doc:`individual documentation for that attribute <AttributeReference>`.
+
+The attributes are applied to all matching declarations individually, even when
+the attribute is semantically incorrect. The attributes that aren't applied to
+any declaration are not verified semantically.
+
+Specifying section names for global objects (#pragma clang section)
+===================================================================
+
+The ``#pragma clang section`` directive provides a means to assign section-names
+to global variables, functions and static variables.
+
+The section names can be specified as:
+
+.. code-block:: c++
+
+ #pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText"
+
+The section names can be reverted back to default name by supplying an empty
+string to the section kind, for example:
+
+.. code-block:: c++
+
+ #pragma clang section bss="" data="" text="" rodata=""
+
+The ``#pragma clang section`` directive obeys the following rules:
+
+* The pragma applies to all global variable, statics and function declarations
+ from the pragma to the end of the translation unit.
+
+* The pragma clang section is enabled automatically, without need of any flags.
+
+* This feature is only defined to work sensibly for ELF targets.
+
+* If section name is specified through _attribute_((section("myname"))), then
+ the attribute name gains precedence.
+
+* Global variables that are initialized to zero will be placed in the named
+ bss section, if one is present.
+
+* The ``#pragma clang section`` directive does not does try to infer section-kind
+ from the name. For example, naming a section "``.bss.mySec``" does NOT mean
+ it will be a bss section name.
+
+* The decision about which section-kind applies to each global is taken in the back-end.
+ Once the section-kind is known, appropriate section name, as specified by the user using
+ ``#pragma clang section`` directive, is applied to that global.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/LeakSanitizer.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/LeakSanitizer.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/LeakSanitizer.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/LeakSanitizer.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,49 @@
+================
+LeakSanitizer
+================
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+LeakSanitizer is a run-time memory leak detector. It can be combined with
+:doc:`AddressSanitizer` to get both memory error and leak detection, or
+used in a stand-alone mode. LSan adds almost no performance overhead
+until the very end of the process, at which point there is an extra leak
+detection phase.
+
+Usage
+=====
+
+LeakSanitizer is only supported on x86\_64 Linux. In order to use it,
+simply build your program with :doc:`AddressSanitizer`:
+
+.. code-block:: console
+
+ $ cat memory-leak.c
+ #include <stdlib.h>
+ void *p;
+ int main() {
+ p = malloc(7);
+ p = 0; // The memory is leaked here.
+ return 0;
+ }
+ % clang -fsanitize=address -g memory-leak.c ; ./a.out
+ ==23646==ERROR: LeakSanitizer: detected memory leaks
+ Direct leak of 7 byte(s) in 1 object(s) allocated from:
+ #0 0x4af01b in __interceptor_malloc /projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52:3
+ #1 0x4da26a in main memory-leak.c:4:7
+ #2 0x7f076fd9cec4 in __libc_start_main libc-start.c:287
+ SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s).
+
+To use LeakSanitizer in stand-alone mode, link your program with
+``-fsanitize=leak`` flag. Make sure to use ``clang`` (not ``ld``) for the
+link step, so that it would link in proper LeakSanitizer run-time library
+into the final executable.
+
+More Information
+================
+
+`<https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer>`_
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibASTMatchers.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibASTMatchers.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibASTMatchers.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibASTMatchers.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,134 @@
+======================
+Matching the Clang AST
+======================
+
+This document explains how to use Clang's LibASTMatchers to match interesting
+nodes of the AST and execute code that uses the matched nodes. Combined with
+:doc:`LibTooling`, LibASTMatchers helps to write code-to-code transformation
+tools or query tools.
+
+We assume basic knowledge about the Clang AST. See the :doc:`Introduction
+to the Clang AST <IntroductionToTheClangAST>` if you want to learn more
+about how the AST is structured.
+
+.. FIXME: create tutorial and link to the tutorial
+
+Introduction
+------------
+
+LibASTMatchers provides a domain specific language to create predicates on
+Clang's AST. This DSL is written in and can be used from C++, allowing users
+to write a single program to both match AST nodes and access the node's C++
+interface to extract attributes, source locations, or any other information
+provided on the AST level.
+
+AST matchers are predicates on nodes in the AST. Matchers are created by
+calling creator functions that allow building up a tree of matchers, where
+inner matchers are used to make the match more specific.
+
+For example, to create a matcher that matches all class or union declarations
+in the AST of a translation unit, you can call `recordDecl()
+<LibASTMatchersReference.html#recordDecl0Anchor>`_. To narrow the match down,
+for example to find all class or union declarations with the name "``Foo``",
+insert a `hasName <LibASTMatchersReference.html#hasName0Anchor>`_ matcher: the
+call ``recordDecl(hasName("Foo"))`` returns a matcher that matches classes or
+unions that are named "``Foo``", in any namespace. By default, matchers that
+accept multiple inner matchers use an implicit `allOf()
+<LibASTMatchersReference.html#allOf0Anchor>`_. This allows further narrowing
+down the match, for example to match all classes that are derived from
+"``Bar``": ``recordDecl(hasName("Foo"), isDerivedFrom("Bar"))``.
+
+How to create a matcher
+-----------------------
+
+With more than a thousand classes in the Clang AST, one can quickly get lost
+when trying to figure out how to create a matcher for a specific pattern. This
+section will teach you how to use a rigorous step-by-step pattern to build the
+matcher you are interested in. Note that there will always be matchers missing
+for some part of the AST. See the section about :ref:`how to write your own
+AST matchers <astmatchers-writing>` later in this document.
+
+.. FIXME: why is it linking back to the same section?!
+
+The precondition to using the matchers is to understand how the AST for what you
+want to match looks like. The
+:doc:`Introduction to the Clang AST <IntroductionToTheClangAST>` teaches you
+how to dump a translation unit's AST into a human readable format.
+
+.. FIXME: Introduce link to ASTMatchersTutorial.html
+.. FIXME: Introduce link to ASTMatchersCookbook.html
+
+In general, the strategy to create the right matchers is:
+
+#. Find the outermost class in Clang's AST you want to match.
+#. Look at the `AST Matcher Reference <LibASTMatchersReference.html>`_ for
+ matchers that either match the node you're interested in or narrow down
+ attributes on the node.
+#. Create your outer match expression. Verify that it works as expected.
+#. Examine the matchers for what the next inner node you want to match is.
+#. Repeat until the matcher is finished.
+
+.. _astmatchers-bind:
+
+Binding nodes in match expressions
+----------------------------------
+
+Matcher expressions allow you to specify which parts of the AST are interesting
+for a certain task. Often you will want to then do something with the nodes
+that were matched, like building source code transformations.
+
+To that end, matchers that match specific AST nodes (so called node matchers)
+are bindable; for example, ``recordDecl(hasName("MyClass")).bind("id")`` will
+bind the matched ``recordDecl`` node to the string "``id``", to be later
+retrieved in the `match callback
+<http://clang.llvm.org/doxygen/classclang_1_1ast__matchers_1_1MatchFinder_1_1MatchCallback.html>`_.
+
+.. FIXME: Introduce link to ASTMatchersTutorial.html
+.. FIXME: Introduce link to ASTMatchersCookbook.html
+
+Writing your own matchers
+-------------------------
+
+There are multiple different ways to define a matcher, depending on its type
+and flexibility.
+
+``VariadicDynCastAllOfMatcher<Base, Derived>``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Those match all nodes of type *Base* if they can be dynamically casted to
+*Derived*. The names of those matchers are nouns, which closely resemble
+*Derived*. ``VariadicDynCastAllOfMatchers`` are the backbone of the matcher
+hierarchy. Most often, your match expression will start with one of them, and
+you can :ref:`bind <astmatchers-bind>` the node they represent to ids for later
+processing.
+
+``VariadicDynCastAllOfMatchers`` are callable classes that model variadic
+template functions in C++03. They take an arbitrary number of
+``Matcher<Derived>`` and return a ``Matcher<Base>``.
+
+``AST_MATCHER_P(Type, Name, ParamType, Param)``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Most matcher definitions use the matcher creation macros. Those define both
+the matcher of type ``Matcher<Type>`` itself, and a matcher-creation function
+named *Name* that takes a parameter of type *ParamType* and returns the
+corresponding matcher.
+
+There are multiple matcher definition macros that deal with polymorphic return
+values and different parameter counts. See `ASTMatchersMacros.h
+<http://clang.llvm.org/doxygen/ASTMatchersMacros_8h.html>`_.
+
+.. _astmatchers-writing:
+
+Matcher creation functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matchers are generated by nesting calls to matcher creation functions. Most of
+the time those functions are either created by using
+``VariadicDynCastAllOfMatcher`` or the matcher creation macros (see below).
+The free-standing functions are an indication that this matcher is just a
+combination of other matchers, as is for example the case with `callee
+<LibASTMatchersReference.html#callee1Anchor>`_.
+
+.. FIXME: "... macros (see below)" --- there isn't anything below
+
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibASTMatchersTutorial.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibASTMatchersTutorial.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibASTMatchersTutorial.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibASTMatchersTutorial.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,559 @@
+===============================================================
+Tutorial for building tools using LibTooling and LibASTMatchers
+===============================================================
+
+This document is intended to show how to build a useful source-to-source
+translation tool based on Clang's `LibTooling <LibTooling.html>`_. It is
+explicitly aimed at people who are new to Clang, so all you should need
+is a working knowledge of C++ and the command line.
+
+In order to work on the compiler, you need some basic knowledge of the
+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 <http://llvm.org/docs/GettingStarted.html>`_.
+
+.. code-block:: console
+
+ mkdir ~/clang-llvm && cd ~/clang-llvm
+ git clone http://llvm.org/git/llvm.git
+ cd llvm/tools
+ git clone http://llvm.org/git/clang.git
+ cd clang/tools
+ git clone http://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.
+
+.. 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.
+ 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.
+
+Finally, we want to set Clang as its own compiler.
+
+.. code-block:: console
+
+ cd ~/clang-llvm/build
+ ccmake ../llvm
+
+The second command will bring up a GUI for configuring Clang. You need
+to set the entry for ``CMAKE_CXX_COMPILER``. Press ``'t'`` to turn on
+advanced mode. Scroll down to ``CMAKE_CXX_COMPILER``, and set it to
+``/usr/bin/clang++``, or wherever you installed it. Press ``'c'`` to
+configure, then ``'g'`` to generate CMake's files.
+
+Finally, run ninja one last time, and you're done.
+
+Step 1: Create a ClangTool
+==========================
+
+Now that we have enough background knowledge, it's time to create the
+simplest productive ClangTool in existence: a syntax checker. While this
+already exists as ``clang-check``, it's important to understand what's
+going on.
+
+First, we'll need to create a new directory for our tool and tell CMake
+that it exists. As this is not going to be a core clang tool, it will
+live in the ``tools/extra`` repository.
+
+.. code-block:: console
+
+ cd ~/clang-llvm/llvm/tools/clang
+ mkdir tools/extra/loop-convert
+ echo 'add_subdirectory(loop-convert)' >> tools/extra/CMakeLists.txt
+ vim tools/extra/loop-convert/CMakeLists.txt
+
+CMakeLists.txt should have the following contents:
+
+::
+
+ set(LLVM_LINK_COMPONENTS support)
+
+ add_clang_executable(loop-convert
+ LoopConvert.cpp
+ )
+ target_link_libraries(loop-convert
+ clangTooling
+ clangBasic
+ clangASTMatchers
+ )
+
+With that done, Ninja will be able to compile our tool. Let's give it
+something to compile! Put the following into
+``tools/extra/loop-convert/LoopConvert.cpp``. A detailed explanation of
+why the different parts are needed can be found in the `LibTooling
+documentation <LibTooling.html>`_.
+
+.. code-block:: c++
+
+ // Declares clang::SyntaxOnlyAction.
+ #include "clang/Frontend/FrontendActions.h"
+ #include "clang/Tooling/CommonOptionsParser.h"
+ #include "clang/Tooling/Tooling.h"
+ // Declares llvm::cl::extrahelp.
+ #include "llvm/Support/CommandLine.h"
+
+ using namespace clang::tooling;
+ using namespace llvm;
+
+ // Apply a custom category to all command-line options so that they are the
+ // only ones displayed.
+ static llvm::cl::OptionCategory MyToolCategory("my-tool options");
+
+ // CommonOptionsParser declares HelpMessage with a description of the common
+ // command-line options related to the compilation database and input files.
+ // It's nice to have this help message in all tools.
+ static cl::extrahelp CommonHelp(CommonOptionsParser::HelpMessage);
+
+ // A help message for this specific tool can be added afterwards.
+ static cl::extrahelp MoreHelp("\nMore help text...");
+
+ int main(int argc, const char **argv) {
+ CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
+ ClangTool Tool(OptionsParser.getCompilations(),
+ OptionsParser.getSourcePathList());
+ return Tool.run(newFrontendActionFactory<clang::SyntaxOnlyAction>().get());
+ }
+
+And that's it! You can compile our new tool by running ninja from the
+``build`` directory.
+
+.. code-block:: console
+
+ cd ~/clang-llvm/build
+ ninja
+
+You should now be able to run the syntax checker, which is located in
+``~/clang-llvm/build/bin``, on any source file. Try it!
+
+.. code-block:: console
+
+ echo "int main() { return 0; }" > test.cpp
+ bin/loop-convert test.cpp --
+
+Note the two dashes after we specify the source file. The additional
+options for the compiler are passed after the dashes rather than loading
+them from a compilation database - there just aren't any options needed
+right now.
+
+Intermezzo: Learn AST matcher basics
+====================================
+
+Clang recently introduced the :doc:`ASTMatcher
+library <LibASTMatchers>` to provide a simple, powerful, and
+concise way to describe specific patterns in the AST. Implemented as a
+DSL powered by macros and templates (see
+`ASTMatchers.h <../doxygen/ASTMatchers_8h_source.html>`_ if you're
+curious), matchers offer the feel of algebraic data types common to
+functional programming languages.
+
+For example, suppose you wanted to examine only binary operators. There
+is a matcher to do exactly that, conveniently named ``binaryOperator``.
+I'll give you one guess what this matcher does:
+
+.. code-block:: c++
+
+ binaryOperator(hasOperatorName("+"), hasLHS(integerLiteral(equals(0))))
+
+Shockingly, it will match against addition expressions whose left hand
+side is exactly the literal 0. It will not match against other forms of
+0, such as ``'\0'`` or ``NULL``, but it will match against macros that
+expand to 0. The matcher will also not match against calls to the
+overloaded operator ``'+'``, as there is a separate ``operatorCallExpr``
+matcher to handle overloaded operators.
+
+There are AST matchers to match all the different nodes of the AST,
+narrowing matchers to only match AST nodes fulfilling specific criteria,
+and traversal matchers to get from one kind of AST node to another. For
+a complete list of AST matchers, take a look at the `AST Matcher
+References <LibASTMatchersReference.html>`_
+
+All matcher that are nouns describe entities in the AST and can be
+bound, so that they can be referred to whenever a match is found. To do
+so, simply call the method ``bind`` on these matchers, e.g.:
+
+.. code-block:: c++
+
+ variable(hasType(isInteger())).bind("intvar")
+
+Step 2: Using AST matchers
+==========================
+
+Okay, on to using matchers for real. Let's start by defining a matcher
+which will capture all ``for`` statements that define a new variable
+initialized to zero. Let's start with matching all ``for`` loops:
+
+.. code-block:: c++
+
+ forStmt()
+
+Next, we want to specify that a single variable is declared in the first
+portion of the loop, so we can extend the matcher to
+
+.. code-block:: c++
+
+ forStmt(hasLoopInit(declStmt(hasSingleDecl(varDecl()))))
+
+Finally, we can add the condition that the variable is initialized to
+zero.
+
+.. code-block:: c++
+
+ forStmt(hasLoopInit(declStmt(hasSingleDecl(varDecl(
+ hasInitializer(integerLiteral(equals(0))))))))
+
+It is fairly easy to read and understand the matcher definition ("match
+loops whose init portion declares a single variable which is initialized
+to the integer literal 0"), but deciding that every piece is necessary
+is more difficult. Note that this matcher will not match loops whose
+variables are initialized to ``'\0'``, ``0.0``, ``NULL``, or any form of
+zero besides the integer 0.
+
+The last step is giving the matcher a name and binding the ``ForStmt``
+as we will want to do something with it:
+
+.. code-block:: c++
+
+ StatementMatcher LoopMatcher =
+ forStmt(hasLoopInit(declStmt(hasSingleDecl(varDecl(
+ hasInitializer(integerLiteral(equals(0)))))))).bind("forLoop");
+
+Once you have defined your matchers, you will need to add a little more
+scaffolding in order to run them. Matchers are paired with a
+``MatchCallback`` and registered with a ``MatchFinder`` object, then run
+from a ``ClangTool``. More code!
+
+Add the following to ``LoopConvert.cpp``:
+
+.. code-block:: c++
+
+ #include "clang/ASTMatchers/ASTMatchers.h"
+ #include "clang/ASTMatchers/ASTMatchFinder.h"
+
+ using namespace clang;
+ using namespace clang::ast_matchers;
+
+ StatementMatcher LoopMatcher =
+ forStmt(hasLoopInit(declStmt(hasSingleDecl(varDecl(
+ hasInitializer(integerLiteral(equals(0)))))))).bind("forLoop");
+
+ class LoopPrinter : public MatchFinder::MatchCallback {
+ public :
+ virtual void run(const MatchFinder::MatchResult &Result) {
+ if (const ForStmt *FS = Result.Nodes.getNodeAs<clang::ForStmt>("forLoop"))
+ FS->dump();
+ }
+ };
+
+And change ``main()`` to:
+
+.. code-block:: c++
+
+ int main(int argc, const char **argv) {
+ CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
+ ClangTool Tool(OptionsParser.getCompilations(),
+ OptionsParser.getSourcePathList());
+
+ LoopPrinter Printer;
+ MatchFinder Finder;
+ Finder.addMatcher(LoopMatcher, &Printer);
+
+ return Tool.run(newFrontendActionFactory(&Finder).get());
+ }
+
+Now, you should be able to recompile and run the code to discover for
+loops. Create a new file with a few examples, and test out our new
+handiwork:
+
+.. code-block:: console
+
+ cd ~/clang-llvm/llvm/llvm_build/
+ ninja loop-convert
+ vim ~/test-files/simple-loops.cc
+ bin/loop-convert ~/test-files/simple-loops.cc
+
+Step 3.5: More Complicated Matchers
+===================================
+
+Our simple matcher is capable of discovering for loops, but we would
+still need to filter out many more ourselves. We can do a good portion
+of the remaining work with some cleverly chosen matchers, but first we
+need to decide exactly which properties we want to allow.
+
+How can we characterize for loops over arrays which would be eligible
+for translation to range-based syntax? Range based loops over arrays of
+size ``N`` that:
+
+- start at index ``0``
+- iterate consecutively
+- end at index ``N-1``
+
+We already check for (1), so all we need to add is a check to the loop's
+condition to ensure that the loop's index variable is compared against
+``N`` and another check to ensure that the increment step just
+increments this same variable. The matcher for (2) is straightforward:
+require a pre- or post-increment of the same variable declared in the
+init portion.
+
+Unfortunately, such a matcher is impossible to write. Matchers contain
+no logic for comparing two arbitrary AST nodes and determining whether
+or not they are equal, so the best we can do is matching more than we
+would like to allow, and punting extra comparisons to the callback.
+
+In any case, we can start building this sub-matcher. We can require that
+the increment step be a unary increment like this:
+
+.. code-block:: c++
+
+ hasIncrement(unaryOperator(hasOperatorName("++")))
+
+Specifying what is incremented introduces another quirk of Clang's AST:
+Usages of variables are represented as ``DeclRefExpr``'s ("declaration
+reference expressions") because they are expressions which refer to
+variable declarations. To find a ``unaryOperator`` that refers to a
+specific declaration, we can simply add a second condition to it:
+
+.. code-block:: c++
+
+ hasIncrement(unaryOperator(
+ hasOperatorName("++"),
+ hasUnaryOperand(declRefExpr())))
+
+Furthermore, we can restrict our matcher to only match if the
+incremented variable is an integer:
+
+.. code-block:: c++
+
+ hasIncrement(unaryOperator(
+ hasOperatorName("++"),
+ hasUnaryOperand(declRefExpr(to(varDecl(hasType(isInteger())))))))
+
+And the last step will be to attach an identifier to this variable, so
+that we can retrieve it in the callback:
+
+.. code-block:: c++
+
+ hasIncrement(unaryOperator(
+ hasOperatorName("++"),
+ hasUnaryOperand(declRefExpr(to(
+ varDecl(hasType(isInteger())).bind("incrementVariable"))))))
+
+We can add this code to the definition of ``LoopMatcher`` and make sure
+that our program, outfitted with the new matcher, only prints out loops
+that declare a single variable initialized to zero and have an increment
+step consisting of a unary increment of some variable.
+
+Now, we just need to add a matcher to check if the condition part of the
+``for`` loop compares a variable against the size of the array. There is
+only one problem - we don't know which array we're iterating over
+without looking at the body of the loop! We are again restricted to
+approximating the result we want with matchers, filling in the details
+in the callback. So we start with:
+
+.. code-block:: c++
+
+ hasCondition(binaryOperator(hasOperatorName("<"))
+
+It makes sense to ensure that the left-hand side is a reference to a
+variable, and that the right-hand side has integer type.
+
+.. code-block:: c++
+
+ hasCondition(binaryOperator(
+ hasOperatorName("<"),
+ hasLHS(declRefExpr(to(varDecl(hasType(isInteger()))))),
+ hasRHS(expr(hasType(isInteger())))))
+
+Why? Because it doesn't work. Of the three loops provided in
+``test-files/simple.cpp``, zero of them have a matching condition. A
+quick look at the AST dump of the first for loop, produced by the
+previous iteration of loop-convert, shows us the answer:
+
+::
+
+ (ForStmt 0x173b240
+ (DeclStmt 0x173afc8
+ 0x173af50 "int i =
+ (IntegerLiteral 0x173afa8 'int' 0)")
+ <<>>
+ (BinaryOperator 0x173b060 '_Bool' '<'
+ (ImplicitCastExpr 0x173b030 'int'
+ (DeclRefExpr 0x173afe0 'int' lvalue Var 0x173af50 'i' 'int'))
+ (ImplicitCastExpr 0x173b048 'int'
+ (DeclRefExpr 0x173b008 'const int' lvalue Var 0x170fa80 'N' 'const int')))
+ (UnaryOperator 0x173b0b0 'int' lvalue prefix '++'
+ (DeclRefExpr 0x173b088 'int' lvalue Var 0x173af50 'i' 'int'))
+ (CompoundStatement ...
+
+We already know that the declaration and increments both match, or this
+loop wouldn't have been dumped. The culprit lies in the implicit cast
+applied to the first operand (i.e. the LHS) of the less-than operator,
+an L-value to R-value conversion applied to the expression referencing
+``i``. Thankfully, the matcher library offers a solution to this problem
+in the form of ``ignoringParenImpCasts``, which instructs the matcher to
+ignore implicit casts and parentheses before continuing to match.
+Adjusting the condition operator will restore the desired match.
+
+.. code-block:: c++
+
+ hasCondition(binaryOperator(
+ hasOperatorName("<"),
+ hasLHS(ignoringParenImpCasts(declRefExpr(
+ to(varDecl(hasType(isInteger())))))),
+ hasRHS(expr(hasType(isInteger())))))
+
+After adding binds to the expressions we wished to capture and
+extracting the identifier strings into variables, we have array-step-2
+completed.
+
+Step 4: Retrieving Matched Nodes
+================================
+
+So far, the matcher callback isn't very interesting: it just dumps the
+loop's AST. At some point, we will need to make changes to the input
+source code. Next, we'll work on using the nodes we bound in the
+previous step.
+
+The ``MatchFinder::run()`` callback takes a
+``MatchFinder::MatchResult&`` as its parameter. We're most interested in
+its ``Context`` and ``Nodes`` members. Clang uses the ``ASTContext``
+class to represent contextual information about the AST, as the name
+implies, though the most functionally important detail is that several
+operations require an ``ASTContext*`` parameter. More immediately useful
+is the set of matched nodes, and how we retrieve them.
+
+Since we bind three variables (identified by ConditionVarName,
+InitVarName, and IncrementVarName), we can obtain the matched nodes by
+using the ``getNodeAs()`` member function.
+
+In ``LoopConvert.cpp`` add
+
+.. code-block:: c++
+
+ #include "clang/AST/ASTContext.h"
+
+Change ``LoopMatcher`` to
+
+.. code-block:: c++
+
+ StatementMatcher LoopMatcher =
+ forStmt(hasLoopInit(declStmt(
+ hasSingleDecl(varDecl(hasInitializer(integerLiteral(equals(0))))
+ .bind("initVarName")))),
+ hasIncrement(unaryOperator(
+ hasOperatorName("++"),
+ hasUnaryOperand(declRefExpr(
+ to(varDecl(hasType(isInteger())).bind("incVarName")))))),
+ hasCondition(binaryOperator(
+ hasOperatorName("<"),
+ hasLHS(ignoringParenImpCasts(declRefExpr(
+ to(varDecl(hasType(isInteger())).bind("condVarName"))))),
+ hasRHS(expr(hasType(isInteger())))))).bind("forLoop");
+
+And change ``LoopPrinter::run`` to
+
+.. code-block:: c++
+
+ void LoopPrinter::run(const MatchFinder::MatchResult &Result) {
+ ASTContext *Context = Result.Context;
+ const ForStmt *FS = Result.Nodes.getNodeAs<ForStmt>("forLoop");
+ // We do not want to convert header files!
+ if (!FS || !Context->getSourceManager().isWrittenInMainFile(FS->getForLoc()))
+ return;
+ const VarDecl *IncVar = Result.Nodes.getNodeAs<VarDecl>("incVarName");
+ const VarDecl *CondVar = Result.Nodes.getNodeAs<VarDecl>("condVarName");
+ const VarDecl *InitVar = Result.Nodes.getNodeAs<VarDecl>("initVarName");
+
+ if (!areSameVariable(IncVar, CondVar) || !areSameVariable(IncVar, InitVar))
+ return;
+ llvm::outs() << "Potential array-based loop discovered.\n";
+ }
+
+Clang associates a ``VarDecl`` with each variable to represent the variable's
+declaration. Since the "canonical" form of each declaration is unique by
+address, all we need to do is make sure neither ``ValueDecl`` (base class of
+``VarDecl``) is ``NULL`` and compare the canonical Decls.
+
+.. code-block:: c++
+
+ static bool areSameVariable(const ValueDecl *First, const ValueDecl *Second) {
+ return First && Second &&
+ First->getCanonicalDecl() == Second->getCanonicalDecl();
+ }
+
+If execution reaches the end of ``LoopPrinter::run()``, we know that the
+loop shell that looks like
+
+.. code-block:: c++
+
+ for (int i= 0; i < expr(); ++i) { ... }
+
+For now, we will just print a message explaining that we found a loop.
+The next section will deal with recursively traversing the AST to
+discover all changes needed.
+
+As a side note, it's not as trivial to test if two expressions are the same,
+though Clang has already done the hard work for us by providing a way to
+canonicalize expressions:
+
+.. code-block:: c++
+
+ static bool areSameExpr(ASTContext *Context, const Expr *First,
+ const Expr *Second) {
+ if (!First || !Second)
+ return false;
+ llvm::FoldingSetNodeID FirstID, SecondID;
+ First->Profile(FirstID, *Context, true);
+ Second->Profile(SecondID, *Context, true);
+ return FirstID == SecondID;
+ }
+
+This code relies on the comparison between two
+``llvm::FoldingSetNodeIDs``. As the documentation for
+``Stmt::Profile()`` indicates, the ``Profile()`` member function builds
+a description of a node in the AST, based on its properties, along with
+those of its children. ``FoldingSetNodeID`` then serves as a hash we can
+use to compare expressions. We will need ``areSameExpr`` later. Before
+you run the new code on the additional loops added to
+test-files/simple.cpp, try to figure out which ones will be considered
+potentially convertible.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibFormat.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibFormat.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibFormat.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibFormat.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,58 @@
+=========
+LibFormat
+=========
+
+LibFormat is a library that implements automatic source code formatting based
+on Clang. This documents describes the LibFormat interface and design as well
+as some basic style discussions.
+
+If you just want to use `clang-format` as a tool or integrated into an editor,
+checkout :doc:`ClangFormat`.
+
+Design
+------
+
+FIXME: Write up design.
+
+
+Interface
+---------
+
+The core routine of LibFormat is ``reformat()``:
+
+.. code-block:: c++
+
+ tooling::Replacements reformat(const FormatStyle &Style, Lexer &Lex,
+ SourceManager &SourceMgr,
+ std::vector<CharSourceRange> Ranges);
+
+This reads a token stream out of the lexer ``Lex`` and reformats all the code
+ranges in ``Ranges``. The ``FormatStyle`` controls basic decisions made during
+formatting. A list of options can be found under :ref:`style-options`.
+
+The style options are described in :doc:`ClangFormatStyleOptions`.
+
+
+.. _style-options:
+
+Style Options
+-------------
+
+The style options describe specific formatting options that can be used in
+order to make `ClangFormat` comply with different style guides. Currently,
+two style guides are hard-coded:
+
+.. code-block:: c++
+
+ /// \brief Returns a format style complying with the LLVM coding standards:
+ /// http://llvm.org/docs/CodingStandards.html.
+ FormatStyle getLLVMStyle();
+
+ /// \brief Returns a format style complying with Google's C++ style guide:
+ /// http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml.
+ FormatStyle getGoogleStyle();
+
+These options are also exposed in the :doc:`standalone tools <ClangFormat>`
+through the `-style` option.
+
+In the future, we plan on making this configurable.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibTooling.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibTooling.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibTooling.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/LibTooling.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,201 @@
+==========
+LibTooling
+==========
+
+LibTooling is a library to support writing standalone tools based on Clang.
+This document will provide a basic walkthrough of how to write a tool using
+LibTooling.
+
+For the information on how to setup Clang Tooling for LLVM see
+:doc:`HowToSetupToolingForLLVM`
+
+Introduction
+------------
+
+Tools built with LibTooling, like Clang Plugins, run ``FrontendActions`` over
+code.
+
+.. See FIXME for a tutorial on how to write FrontendActions.
+
+In this tutorial, we'll demonstrate the different ways of running Clang's
+``SyntaxOnlyAction``, which runs a quick syntax check, over a bunch of code.
+
+Parsing a code snippet in memory
+--------------------------------
+
+If you ever wanted to run a ``FrontendAction`` over some sample code, for
+example to unit test parts of the Clang AST, ``runToolOnCode`` is what you
+looked for. Let me give you an example:
+
+.. code-block:: c++
+
+ #include "clang/Tooling/Tooling.h"
+
+ TEST(runToolOnCode, CanSyntaxCheckCode) {
+ // runToolOnCode returns whether the action was correctly run over the
+ // given code.
+ EXPECT_TRUE(runToolOnCode(new clang::SyntaxOnlyAction, "class X {};"));
+ }
+
+Writing a standalone tool
+-------------------------
+
+Once you unit tested your ``FrontendAction`` to the point where it cannot
+possibly break, it's time to create a standalone tool. For a standalone tool
+to run clang, it first needs to figure out what command line arguments to use
+for a specified file. To that end we create a ``CompilationDatabase``. There
+are different ways to create a compilation database, and we need to support all
+of them depending on command-line options. There's the ``CommonOptionsParser``
+class that takes the responsibility to parse command-line parameters related to
+compilation databases and inputs, so that all tools share the implementation.
+
+Parsing common tools options
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``CompilationDatabase`` can be read from a build directory or the command line.
+Using ``CommonOptionsParser`` allows for explicit specification of a compile
+command line, specification of build path using the ``-p`` command-line option,
+and automatic location of the compilation database using source files paths.
+
+.. code-block:: c++
+
+ #include "clang/Tooling/CommonOptionsParser.h"
+ #include "llvm/Support/CommandLine.h"
+
+ using namespace clang::tooling;
+
+ // Apply a custom category to all command-line options so that they are the
+ // only ones displayed.
+ static llvm::cl::OptionCategory MyToolCategory("my-tool options");
+
+ int main(int argc, const char **argv) {
+ // CommonOptionsParser constructor will parse arguments and create a
+ // CompilationDatabase. In case of error it will terminate the program.
+ CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
+
+ // Use OptionsParser.getCompilations() and OptionsParser.getSourcePathList()
+ // to retrieve CompilationDatabase and the list of input file paths.
+ }
+
+Creating and running a ClangTool
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once we have a ``CompilationDatabase``, we can create a ``ClangTool`` and run
+our ``FrontendAction`` over some code. For example, to run the
+``SyntaxOnlyAction`` over the files "a.cc" and "b.cc" one would write:
+
+.. code-block:: c++
+
+ // A clang tool can run over a number of sources in the same process...
+ std::vector<std::string> Sources;
+ Sources.push_back("a.cc");
+ Sources.push_back("b.cc");
+
+ // We hand the CompilationDatabase we created and the sources to run over into
+ // the tool constructor.
+ ClangTool Tool(OptionsParser.getCompilations(), Sources);
+
+ // The ClangTool needs a new FrontendAction for each translation unit we run
+ // on. Thus, it takes a FrontendActionFactory as parameter. To create a
+ // FrontendActionFactory from a given FrontendAction type, we call
+ // newFrontendActionFactory<clang::SyntaxOnlyAction>().
+ int result = Tool.run(newFrontendActionFactory<clang::SyntaxOnlyAction>().get());
+
+Putting it together --- the first tool
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Now we combine the two previous steps into our first real tool. A more advanced
+version of this example tool is also checked into the clang tree at
+``tools/clang-check/ClangCheck.cpp``.
+
+.. code-block:: c++
+
+ // Declares clang::SyntaxOnlyAction.
+ #include "clang/Frontend/FrontendActions.h"
+ #include "clang/Tooling/CommonOptionsParser.h"
+ #include "clang/Tooling/Tooling.h"
+ // Declares llvm::cl::extrahelp.
+ #include "llvm/Support/CommandLine.h"
+
+ using namespace clang::tooling;
+ using namespace llvm;
+
+ // Apply a custom category to all command-line options so that they are the
+ // only ones displayed.
+ static cl::OptionCategory MyToolCategory("my-tool options");
+
+ // CommonOptionsParser declares HelpMessage with a description of the common
+ // command-line options related to the compilation database and input files.
+ // It's nice to have this help message in all tools.
+ static cl::extrahelp CommonHelp(CommonOptionsParser::HelpMessage);
+
+ // A help message for this specific tool can be added afterwards.
+ static cl::extrahelp MoreHelp("\nMore help text...");
+
+ int main(int argc, const char **argv) {
+ CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
+ ClangTool Tool(OptionsParser.getCompilations(),
+ OptionsParser.getSourcePathList());
+ return Tool.run(newFrontendActionFactory<clang::SyntaxOnlyAction>().get());
+ }
+
+Running the tool on some code
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When you check out and build clang, clang-check is already built and available
+to you in bin/clang-check inside your build directory.
+
+You can run clang-check on a file in the llvm repository by specifying all the
+needed parameters after a "``--``" separator:
+
+.. code-block:: bash
+
+ $ cd /path/to/source/llvm
+ $ export BD=/path/to/build/llvm
+ $ $BD/bin/clang-check tools/clang/tools/clang-check/ClangCheck.cpp -- \
+ clang++ -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS \
+ -Itools/clang/include -I$BD/include -Iinclude \
+ -Itools/clang/lib/Headers -c
+
+As an alternative, you can also configure cmake to output a compile command
+database into its build directory:
+
+.. code-block:: bash
+
+ # Alternatively to calling cmake, use ccmake, toggle to advanced mode and
+ # set the parameter CMAKE_EXPORT_COMPILE_COMMANDS from the UI.
+ $ cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON .
+
+This creates a file called ``compile_commands.json`` in the build directory.
+Now you can run :program:`clang-check` over files in the project by specifying
+the build path as first argument and some source files as further positional
+arguments:
+
+.. code-block:: bash
+
+ $ cd /path/to/source/llvm
+ $ export BD=/path/to/build/llvm
+ $ $BD/bin/clang-check -p $BD tools/clang/tools/clang-check/ClangCheck.cpp
+
+
+.. _libtooling_builtin_includes:
+
+Builtin includes
+^^^^^^^^^^^^^^^^
+
+Clang tools need their builtin headers and search for them the same way Clang
+does. Thus, the default location to look for builtin headers is in a path
+``$(dirname /path/to/tool)/../lib/clang/3.3/include`` relative to the tool
+binary. This works out-of-the-box for tools running from llvm's toplevel
+binary directory after building clang-headers, or if the tool is running from
+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
+<http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-check/Makefile?view=markup>`_).
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/MSVCCompatibility.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/MSVCCompatibility.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/MSVCCompatibility.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/MSVCCompatibility.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,156 @@
+.. raw:: html
+
+ <style type="text/css">
+ .none { background-color: #FFCCCC }
+ .partial { background-color: #FFFF99 }
+ .good { background-color: #CCFF99 }
+ </style>
+
+.. role:: none
+.. role:: partial
+.. role:: good
+
+==================
+MSVC compatibility
+==================
+
+When Clang compiles C++ code for Windows, it attempts to be compatible with
+MSVC. There are multiple dimensions to compatibility.
+
+First, Clang attempts to be ABI-compatible, meaning that Clang-compiled code
+should be able to link against MSVC-compiled code successfully. However, C++
+ABIs are particularly large and complicated, and Clang's support for MSVC's C++
+ABI is a work in progress. If you don't require MSVC ABI compatibility or don't
+want to use Microsoft's C and C++ runtimes, the mingw32 toolchain might be a
+better fit for your project.
+
+Second, Clang implements many MSVC language extensions, such as
+``__declspec(dllexport)`` and a handful of pragmas. These are typically
+controlled by ``-fms-extensions``.
+
+Third, MSVC accepts some C++ code that Clang will typically diagnose as
+invalid. When these constructs are present in widely included system headers,
+Clang attempts to recover and continue compiling the user's program. Most
+parsing and semantic compatibility tweaks are controlled by
+``-fms-compatibility`` and ``-fdelayed-template-parsing``, and they are a work
+in progress.
+
+Finally, there is :ref:`clang-cl`, a driver program for clang that attempts to
+be compatible with MSVC's cl.exe.
+
+ABI features
+============
+
+The status of major ABI-impacting C++ features:
+
+* Record layout: :good:`Complete`. We've tested this with a fuzzer and have
+ fixed all known bugs.
+
+* Class inheritance: :good:`Mostly complete`. This covers all of the standard
+ OO features you would expect: virtual method inheritance, multiple
+ inheritance, and virtual inheritance. Every so often we uncover a bug where
+ our tables are incompatible, but this is pretty well in hand. This feature
+ has also been fuzz tested.
+
+* Name mangling: :good:`Ongoing`. Every new C++ feature generally needs its own
+ mangling. For example, member pointer template arguments have an interesting
+ and distinct mangling. Fortunately, incorrect manglings usually do not result
+ in runtime errors. Non-inline functions with incorrect manglings usually
+ result in link errors, which are relatively easy to diagnose. Incorrect
+ manglings for inline functions and templates result in multiple copies in the
+ final image. The C++ standard requires that those addresses be equal, but few
+ programs rely on this.
+
+* 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
+.. _pointer to a member of a virtual base class: http://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.
+
+* RTTI: :good:`Complete`. Generation of RTTI data structures has been
+ finished, along with support for the ``/GR`` flag.
+
+* C++ Exceptions: :good:`Mostly complete`. Support for
+ C++ exceptions (``try`` / ``catch`` / ``throw``) have been implemented for
+ x86 and x64. Our implementation has been well tested but we still get the
+ odd bug report now and again.
+ C++ exception specifications are ignored, but this is `consistent with Visual
+ C++`_.
+
+.. _consistent with Visual C++:
+ https://msdn.microsoft.com/en-us/library/wfa0edys.aspx
+
+* Asynchronous Exceptions (SEH): :partial:`Partial`.
+ Structured exceptions (``__try`` / ``__except`` / ``__finally``) mostly
+ work on x86 and x64.
+ LLVM does not model asynchronous exceptions, so it is currently impossible to
+ catch an asynchronous exception generated in the same frame as the catching
+ ``__try``.
+
+* Thread-safe initialization of local statics: :good:`Complete`. MSVC 2015
+ added support for thread-safe initialization of such variables by taking an
+ ABI break.
+ We are ABI compatible with both the MSVC 2013 and 2015 ABI for static local
+ variables.
+
+* Lambdas: :good:`Mostly complete`. Clang is compatible with Microsoft's
+ implementation of lambdas except for providing overloads for conversion to
+ function pointer for different calling conventions. However, Microsoft's
+ extension is non-conforming.
+
+Template instantiation and name lookup
+======================================
+
+MSVC allows many invalid constructs in class templates that Clang has
+historically rejected. In order to parse widely distributed headers for
+libraries such as the Active Template Library (ATL) and Windows Runtime Library
+(WRL), some template rules have been relaxed or extended in Clang on Windows.
+
+The first major semantic difference is that MSVC appears to defer all parsing
+an analysis of inline method bodies in class templates until instantiation
+time. By default on Windows, Clang attempts to follow suit. This behavior is
+controlled by the ``-fdelayed-template-parsing`` flag. While Clang delays
+parsing of method bodies, it still parses the bodies *before* template argument
+substitution, which is not what MSVC does. The following compatibility tweaks
+are necessary to parse the template in those cases.
+
+MSVC allows some name lookup into dependent base classes. Even on other
+platforms, this has been a `frequently asked question`_ for Clang users. A
+dependent base class is a base class that depends on the value of a template
+parameter. Clang cannot see any of the names inside dependent bases while it
+is parsing your template, so the user is sometimes required to use the
+``typename`` keyword to assist the parser. On Windows, Clang attempts to
+follow the normal lookup rules, but if lookup fails, it will assume that the
+user intended to find the name in a dependent base. While parsing the
+following program, Clang will recover as if the user had written the
+commented-out code:
+
+.. _frequently asked question:
+ http://clang.llvm.org/compatibility.html#dep_lookup
+
+.. code-block:: c++
+
+ template <typename T>
+ struct Foo : T {
+ void f() {
+ /*typename*/ T::UnknownType x = /*this->*/unknownMember;
+ }
+ };
+
+After recovery, Clang warns the user that this code is non-standard and issues
+a hint suggesting how to fix the problem.
+
+As of this writing, Clang is able to compile a simple ATL hello world
+application. There are still issues parsing WRL headers for modern Windows 8
+apps, but they should be addressed soon.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/MemorySanitizer.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/MemorySanitizer.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/MemorySanitizer.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/MemorySanitizer.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,214 @@
+================
+MemorySanitizer
+================
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+MemorySanitizer is a detector of uninitialized reads. It consists of a
+compiler instrumentation module and a run-time library.
+
+Typical slowdown introduced by MemorySanitizer is **3x**.
+
+How to build
+============
+
+Build LLVM/Clang with `CMake <http://llvm.org/docs/CMake.html>`_.
+
+Usage
+=====
+
+Simply compile and link your program with ``-fsanitize=memory`` flag.
+The MemorySanitizer run-time library should be linked to the final
+executable, so make sure to use ``clang`` (not ``ld``) for the final
+link step. When linking shared libraries, the MemorySanitizer run-time
+is not linked, so ``-Wl,-z,defs`` may cause link errors (don't use it
+with MemorySanitizer). To get a reasonable performance add ``-O1`` or
+higher. To get meaningful stack traces in error messages add
+``-fno-omit-frame-pointer``. To get perfect stack traces you may need
+to disable inlining (just use ``-O1``) and tail call elimination
+(``-fno-optimize-sibling-calls``).
+
+.. code-block:: console
+
+ % cat umr.cc
+ #include <stdio.h>
+
+ int main(int argc, char** argv) {
+ int* a = new int[10];
+ a[5] = 0;
+ if (a[argc])
+ printf("xx\n");
+ return 0;
+ }
+
+ % clang -fsanitize=memory -fno-omit-frame-pointer -g -O2 umr.cc
+
+If a bug is detected, the program will print an error message to
+stderr and exit with a non-zero exit code.
+
+.. code-block:: console
+
+ % ./a.out
+ WARNING: MemorySanitizer: use-of-uninitialized-value
+ #0 0x7f45944b418a in main umr.cc:6
+ #1 0x7f45938b676c in __libc_start_main libc-start.c:226
+
+By default, MemorySanitizer exits on the first detected error. If you
+find the error report hard to understand, try enabling
+:ref:`origin tracking <msan-origins>`.
+
+``__has_feature(memory_sanitizer)``
+------------------------------------
+
+In some cases one may need to execute different code depending on
+whether MemorySanitizer is enabled. :ref:`\_\_has\_feature
+<langext-__has_feature-__has_extension>` can be used for this purpose.
+
+.. code-block:: c
+
+ #if defined(__has_feature)
+ # if __has_feature(memory_sanitizer)
+ // code that builds only under MemorySanitizer
+ # endif
+ #endif
+
+``__attribute__((no_sanitize("memory")))``
+-----------------------------------------------
+
+Some code should not be checked by MemorySanitizer. One may use the function
+attribute ``no_sanitize("memory")`` to disable uninitialized checks in a
+particular function. MemorySanitizer may still instrument such functions to
+avoid false positives. This attribute may not be supported by other compilers,
+so we suggest to use it together with ``__has_feature(memory_sanitizer)``.
+
+Blacklist
+---------
+
+MemorySanitizer supports ``src`` and ``fun`` entity types in
+:doc:`SanitizerSpecialCaseList`, that can be used to relax MemorySanitizer
+checks for certain source files and functions. All "Use of uninitialized value"
+warnings will be suppressed and all values loaded from memory will be
+considered fully initialized.
+
+Report symbolization
+====================
+
+MemorySanitizer uses an external symbolizer to print files and line numbers in
+reports. Make sure that ``llvm-symbolizer`` binary is in ``PATH``,
+or set environment variable ``MSAN_SYMBOLIZER_PATH`` to point to it.
+
+.. _msan-origins:
+
+Origin Tracking
+===============
+
+MemorySanitizer can track origins of uninitialized values, similar to
+Valgrind's --track-origins option. This feature is enabled by
+``-fsanitize-memory-track-origins=2`` (or simply
+``-fsanitize-memory-track-origins``) Clang option. With the code from
+the example above,
+
+.. code-block:: console
+
+ % cat umr2.cc
+ #include <stdio.h>
+
+ int main(int argc, char** argv) {
+ int* a = new int[10];
+ a[5] = 0;
+ volatile int b = a[argc];
+ if (b)
+ printf("xx\n");
+ return 0;
+ }
+
+ % clang -fsanitize=memory -fsanitize-memory-track-origins=2 -fno-omit-frame-pointer -g -O2 umr2.cc
+ % ./a.out
+ WARNING: MemorySanitizer: use-of-uninitialized-value
+ #0 0x7f7893912f0b in main umr2.cc:7
+ #1 0x7f789249b76c in __libc_start_main libc-start.c:226
+
+ Uninitialized value was stored to memory at
+ #0 0x7f78938b5c25 in __msan_chain_origin msan.cc:484
+ #1 0x7f7893912ecd in main umr2.cc:6
+
+ Uninitialized value was created by a heap allocation
+ #0 0x7f7893901cbd in operator new[](unsigned long) msan_new_delete.cc:44
+ #1 0x7f7893912e06 in main umr2.cc:4
+
+By default, MemorySanitizer collects both allocation points and all
+intermediate stores the uninitialized value went through. Origin
+tracking has proved to be very useful for debugging MemorySanitizer
+reports. It slows down program execution by a factor of 1.5x-2x on top
+of the usual MemorySanitizer slowdown and increases memory overhead.
+
+Clang option ``-fsanitize-memory-track-origins=1`` enables a slightly
+faster mode when MemorySanitizer collects only allocation points but
+not intermediate stores.
+
+Use-after-destruction detection
+===============================
+
+You can enable experimental use-after-destruction detection in MemorySanitizer.
+After invocation of the destructor, the object will be considered no longer
+readable, and using underlying memory will lead to error reports in runtime.
+
+This feature is still experimental, in order to enable it at runtime you need
+to:
+
+#. Pass addition Clang option ``-fsanitize-memory-use-after-dtor`` during
+ compilation.
+#. Set environment variable `MSAN_OPTIONS=poison_in_dtor=1` before running
+ the program.
+
+Handling external code
+======================
+
+MemorySanitizer requires that all program code is instrumented. This
+also includes any libraries that the program depends on, even libc.
+Failing to achieve this may result in false reports.
+For the same reason you may need to replace all inline assembly code that writes to memory
+with a pure C/C++ code.
+
+Full MemorySanitizer instrumentation is very difficult to achieve. To
+make it easier, MemorySanitizer runtime library includes 70+
+interceptors for the most common libc functions. They make it possible
+to run MemorySanitizer-instrumented programs linked with
+uninstrumented libc. For example, the authors were able to bootstrap
+MemorySanitizer-instrumented Clang compiler by linking it with
+self-built instrumented libc++ (as a replacement for libstdc++).
+
+Supported Platforms
+===================
+
+MemorySanitizer is supported on Linux x86\_64/MIPS64/AArch64.
+
+Limitations
+===========
+
+* MemorySanitizer uses 2x more real memory than a native run, 3x with
+ origin tracking.
+* MemorySanitizer maps (but not reserves) 64 Terabytes of virtual
+ address space. This means that tools like ``ulimit`` may not work as
+ usually expected.
+* Static linking is not supported.
+* Older versions of MSan (LLVM 3.7 and older) didn't work with
+ non-position-independent executables, and could fail on some Linux
+ kernel versions with disabled ASLR. Refer to documentation for older versions
+ for more details.
+
+Current Status
+==============
+
+MemorySanitizer is known to work on large real-world programs
+(like Clang/LLVM itself) that can be recompiled from source, including all
+dependent libraries.
+
+More Information
+================
+
+`<https://github.com/google/sanitizers/wiki/MemorySanitizer>`_
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/Modules.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/Modules.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/Modules.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/Modules.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,948 @@
+=======
+Modules
+=======
+
+.. contents::
+ :local:
+
+Introduction
+============
+Most software is built using a number of software libraries, including libraries supplied by the platform, internal libraries built as part of the software itself to provide structure, and third-party libraries. For each library, one needs to access both its interface (API) and its implementation. In the C family of languages, the interface to a library is accessed by including the appropriate header files(s):
+
+.. code-block:: c
+
+ #include <SomeLib.h>
+
+The implementation is handled separately by linking against the appropriate library. For example, by passing ``-lSomeLib`` to the linker.
+
+Modules provide an alternative, simpler way to use software libraries that provides better compile-time scalability and eliminates many of the problems inherent to using the C preprocessor to access the API of a library.
+
+Problems with the current model
+-------------------------------
+The ``#include`` mechanism provided by the C preprocessor is a very poor way to access the API of a library, for a number of reasons:
+
+* **Compile-time scalability**: Each time a header is included, the
+ compiler must preprocess and parse the text in that header and every
+ header it includes, transitively. This process must be repeated for
+ every translation unit in the application, which involves a huge
+ amount of redundant work. In a project with *N* translation units
+ and *M* headers included in each translation unit, the compiler is
+ performing *M x N* work even though most of the *M* headers are
+ shared among multiple translation units. C++ is particularly bad,
+ because the compilation model for templates forces a huge amount of
+ code into headers.
+
+* **Fragility**: ``#include`` directives are treated as textual
+ inclusion by the preprocessor, and are therefore subject to any
+ active macro definitions at the time of inclusion. If any of the
+ active macro definitions happens to collide with a name in the
+ library, it can break the library API or cause compilation failures
+ in the library header itself. For an extreme example,
+ ``#define std "The C++ Standard"`` and then include a standard
+ library header: the result is a horrific cascade of failures in the
+ C++ Standard Library's implementation. More subtle real-world
+ problems occur when the headers for two different libraries interact
+ due to macro collisions, and users are forced to reorder
+ ``#include`` directives or introduce ``#undef`` directives to break
+ the (unintended) dependency.
+
+* **Conventional workarounds**: C programmers have
+ adopted a number of conventions to work around the fragility of the
+ C preprocessor model. Include guards, for example, are required for
+ the vast majority of headers to ensure that multiple inclusion
+ doesn't break the compile. Macro names are written with
+ ``LONG_PREFIXED_UPPERCASE_IDENTIFIERS`` to avoid collisions, and some
+ library/framework developers even use ``__underscored`` names
+ in headers to avoid collisions with "normal" names that (by
+ convention) shouldn't even be macros. These conventions are a
+ barrier to entry for developers coming from non-C languages, are
+ boilerplate for more experienced developers, and make our headers
+ far uglier than they should be.
+
+* **Tool confusion**: In a C-based language, it is hard to build tools
+ that work well with software libraries, because the boundaries of
+ the libraries are not clear. Which headers belong to a particular
+ library, and in what order should those headers be included to
+ guarantee that they compile correctly? Are the headers C, C++,
+ Objective-C++, or one of the variants of these languages? What
+ declarations in those headers are actually meant to be part of the
+ API, and what declarations are present only because they had to be
+ written as part of the header file?
+
+Semantic import
+---------------
+Modules improve access to the API of software libraries by replacing the textual preprocessor inclusion model with a more robust, more efficient semantic model. From the user's perspective, the code looks only slightly different, because one uses an ``import`` declaration rather than a ``#include`` preprocessor directive:
+
+.. code-block:: c
+
+ import std.io; // pseudo-code; see below for syntax discussion
+
+However, this module import behaves quite differently from the corresponding ``#include <stdio.h>``: when the compiler sees the module import above, it loads a binary representation of the ``std.io`` module and makes its API available to the application directly. Preprocessor definitions that precede the import declaration have no impact on the API provided by ``std.io``, because the module itself was compiled as a separate, standalone module. Additionally, any linker flags required to use the ``std.io`` module will automatically be provided when the module is imported [#]_
+This semantic import model addresses many of the problems of the preprocessor inclusion model:
+
+* **Compile-time scalability**: The ``std.io`` module is only compiled once, and importing the module into a translation unit is a constant-time operation (independent of module system). Thus, the API of each software library is only parsed once, reducing the *M x N* compilation problem to an *M + N* problem.
+
+* **Fragility**: Each module is parsed as a standalone entity, so it has a consistent preprocessor environment. This completely eliminates the need for ``__underscored`` names and similarly defensive tricks. Moreover, the current preprocessor definitions when an import declaration is encountered are ignored, so one software library can not affect how another software library is compiled, eliminating include-order dependencies.
+
+* **Tool confusion**: Modules describe the API of software libraries, and tools can reason about and present a module as a representation of that API. Because modules can only be built standalone, tools can rely on the module definition to ensure that they get the complete API for the library. Moreover, modules can specify which languages they work with, so, e.g., one can not accidentally attempt to load a C++ module into a C program.
+
+Problems modules do not solve
+-----------------------------
+Many programming languages have a module or package system, and because of the variety of features provided by these languages it is important to define what modules do *not* do. In particular, all of the following are considered out-of-scope for modules:
+
+* **Rewrite the world's code**: It is not realistic to require applications or software libraries to make drastic or non-backward-compatible changes, nor is it feasible to completely eliminate headers. Modules must interoperate with existing software libraries and allow a gradual transition.
+
+* **Versioning**: Modules have no notion of version information. Programmers must still rely on the existing versioning mechanisms of the underlying language (if any exist) to version software libraries.
+
+* **Namespaces**: Unlike in some languages, modules do not imply any notion of namespaces. Thus, a struct declared in one module will still conflict with a struct of the same name declared in a different module, just as they would if declared in two different headers. This aspect is important for backward compatibility, because (for example) the mangled names of entities in software libraries must not change when introducing modules.
+
+* **Binary distribution of modules**: Headers (particularly C++ headers) expose the full complexity of the language. Maintaining a stable binary module format across architectures, compiler versions, and compiler vendors is technically infeasible.
+
+Using Modules
+=============
+To enable modules, pass the command-line flag ``-fmodules``. This will make any modules-enabled software libraries available as modules as well as introducing any modules-specific syntax. Additional `command-line parameters`_ are described in a separate section later.
+
+Objective-C Import declaration
+------------------------------
+Objective-C provides syntax for importing a module via an *@import declaration*, which imports the named module:
+
+.. parsed-literal::
+
+ @import std;
+
+The ``@import`` declaration above imports the entire contents of the ``std`` module (which would contain, e.g., the entire C or C++ standard library) and make its API available within the current translation unit. To import only part of a module, one may use dot syntax to specific a particular submodule, e.g.,
+
+.. parsed-literal::
+
+ @import std.io;
+
+Redundant import declarations are ignored, and one is free to import modules at any point within the translation unit, so long as the import declaration is at global scope.
+
+At present, there is no C or C++ syntax for import declarations. Clang
+will track the modules proposal in the C++ committee. See the section
+`Includes as imports`_ to see how modules get imported today.
+
+Includes as imports
+-------------------
+The primary user-level feature of modules is the import operation, which provides access to the API of software libraries. However, today's programs make extensive use of ``#include``, and it is unrealistic to assume that all of this code will change overnight. Instead, modules automatically translate ``#include`` directives into the corresponding module import. For example, the include directive
+
+.. code-block:: c
+
+ #include <stdio.h>
+
+will be automatically mapped to an import of the module ``std.io``. Even with specific ``import`` syntax in the language, this particular feature is important for both adoption and backward compatibility: automatic translation of ``#include`` to ``import`` allows an application to get the benefits of modules (for all modules-enabled libraries) without any changes to the application itself. Thus, users can easily use modules with one compiler while falling back to the preprocessor-inclusion mechanism with other compilers.
+
+.. note::
+
+ The automatic mapping of ``#include`` to ``import`` also solves an implementation problem: importing a module with a definition of some entity (say, a ``struct Point``) and then parsing a header containing another definition of ``struct Point`` would cause a redefinition error, even if it is the same ``struct Point``. By mapping ``#include`` to ``import``, the compiler can guarantee that it always sees just the already-parsed definition from the module.
+
+While building a module, ``#include_next`` is also supported, with one caveat.
+The usual behavior of ``#include_next`` is to search for the specified filename
+in the list of include paths, starting from the path *after* the one
+in which the current file was found.
+Because files listed in module maps are not found through include paths, a
+different strategy is used for ``#include_next`` directives in such files: the
+list of include paths is searched for the specified header name, to find the
+first include path that would refer to the current file. ``#include_next`` is
+interpreted as if the current file had been found in that path.
+If this search finds a file named by a module map, the ``#include_next``
+directive is translated into an import, just like for a ``#include``
+directive.``
+
+Module maps
+-----------
+The crucial link between modules and headers is described by a *module map*, which describes how a collection of existing headers maps on to the (logical) structure of a module. For example, one could imagine a module ``std`` covering the C standard library. Each of the C standard library headers (``<stdio.h>``, ``<stdlib.h>``, ``<math.h>``, etc.) would contribute to the ``std`` module, by placing their respective APIs into the corresponding submodule (``std.io``, ``std.lib``, ``std.math``, etc.). Having a list of the headers that are part of the ``std`` module allows the compiler to build the ``std`` module as a standalone entity, and having the mapping from header names to (sub)modules allows the automatic translation of ``#include`` directives to module imports.
+
+Module maps are specified as separate files (each named ``module.modulemap``) alongside the headers they describe, which allows them to be added to existing software libraries without having to change the library headers themselves (in most cases [#]_). The actual `Module map language`_ is described in a later section.
+
+.. note::
+
+ To actually see any benefits from modules, one first has to introduce module maps for the underlying C standard library and the libraries and headers on which it depends. The section `Modularizing a Platform`_ describes the steps one must take to write these module maps.
+
+One can use module maps without modules to check the integrity of the use of header files. To do this, use the ``-fimplicit-module-maps`` option instead of the ``-fmodules`` option, or use ``-fmodule-map-file=`` option to explicitly specify the module map files to load.
+
+Compilation model
+-----------------
+The binary representation of modules is automatically generated by the compiler on an as-needed basis. When a module is imported (e.g., by an ``#include`` of one of the module's headers), the compiler will spawn a second instance of itself [#]_, with a fresh preprocessing context [#]_, to parse just the headers in that module. The resulting Abstract Syntax Tree (AST) is then persisted into the binary representation of the module that is then loaded into translation unit where the module import was encountered.
+
+The binary representation of modules is persisted in the *module cache*. Imports of a module will first query the module cache and, if a binary representation of the required module is already available, will load that representation directly. Thus, a module's headers will only be parsed once per language configuration, rather than once per translation unit that uses the module.
+
+Modules maintain references to each of the headers that were part of the module build. If any of those headers changes, or if any of the modules on which a module depends change, then the module will be (automatically) recompiled. The process should never require any user intervention.
+
+Command-line parameters
+-----------------------
+``-fmodules``
+ Enable the modules feature.
+
+``-fbuiltin-module-map``
+ Load the Clang builtins module map file. (Equivalent to ``-fmodule-map-file=<resource dir>/include/module.modulemap``)
+
+``-fimplicit-module-maps``
+ Enable implicit search for module map files named ``module.modulemap`` and similar. This option is implied by ``-fmodules``. If this is disabled with ``-fno-implicit-module-maps``, module map files will only be loaded if they are explicitly specified via ``-fmodule-map-file`` or transitively used by another module map file.
+
+``-fmodules-cache-path=<directory>``
+ Specify the path to the modules cache. If not provided, Clang will select a system-appropriate default.
+
+``-fno-autolink``
+ Disable automatic linking against the libraries associated with imported modules.
+
+``-fmodules-ignore-macro=macroname``
+ Instruct modules to ignore the named macro when selecting an appropriate module variant. Use this for macros defined on the command line that don't affect how modules are built, to improve sharing of compiled module files.
+
+``-fmodules-prune-interval=seconds``
+ Specify the minimum delay (in seconds) between attempts to prune the module cache. Module cache pruning attempts to clear out old, unused module files so that the module cache itself does not grow without bound. The default delay is large (604,800 seconds, or 7 days) because this is an expensive operation. Set this value to 0 to turn off pruning.
+
+``-fmodules-prune-after=seconds``
+ Specify the minimum time (in seconds) for which a file in the module cache must be unused (according to access time) before module pruning will remove it. The default delay is large (2,678,400 seconds, or 31 days) to avoid excessive module rebuilding.
+
+``-module-file-info <module file name>``
+ Debugging aid that prints information about a given module file (with a ``.pcm`` extension), including the language and preprocessor options that particular module variant was built with.
+
+``-fmodules-decluse``
+ Enable checking of module ``use`` declarations.
+
+``-fmodule-name=module-id``
+ Consider a source file as a part of the given module.
+
+``-fmodule-map-file=<file>``
+ Load the given module map file if a header from its directory or one of its subdirectories is loaded.
+
+``-fmodules-search-all``
+ If a symbol is not found, search modules referenced in the current module maps but not imported for symbols, so the error message can reference the module by name. Note that if the global module index has not been built before, this might take some time as it needs to build all the modules. Note that this option doesn't apply in module builds, to avoid the recursion.
+
+``-fno-implicit-modules``
+ All modules used by the build must be specified with ``-fmodule-file``.
+
+``-fmodule-file=<file>``
+ Load the given precompiled module file.
+
+``-fprebuilt-module-path=<directory>``
+ Specify the path to the prebuilt modules. If specified, we will look for modules in this directory for a given top-level module name. We don't need a module map for loading prebuilt modules in this directory and the compiler will not try to rebuild these modules. This can be specified multiple times.
+
+Module Semantics
+================
+
+Modules are modeled as if each submodule were a separate translation unit, and a module import makes names from the other translation unit visible. Each submodule starts with a new preprocessor state and an empty translation unit.
+
+.. note::
+
+ This behavior is currently only approximated when building a module with submodules. Entities within a submodule that has already been built are visible when building later submodules in that module. This can lead to fragile modules that depend on the build order used for the submodules of the module, and should not be relied upon. This behavior is subject to change.
+
+As an example, in C, this implies that if two structs are defined in different submodules with the same name, those two types are distinct types (but may be *compatible* types if their definitions match). In C++, two structs defined with the same name in different submodules are the *same* type, and must be equivalent under C++'s One Definition Rule.
+
+.. note::
+
+ Clang currently only performs minimal checking for violations of the One Definition Rule.
+
+If any submodule of a module is imported into any part of a program, the entire top-level module is considered to be part of the program. As a consequence of this, Clang may diagnose conflicts between an entity declared in an unimported submodule and an entity declared in the current translation unit, and Clang may inline or devirtualize based on knowledge from unimported submodules.
+
+Macros
+------
+
+The C and C++ preprocessor assumes that the input text is a single linear buffer, but with modules this is not the case. It is possible to import two modules that have conflicting definitions for a macro (or where one ``#define``\s a macro and the other ``#undef``\ines it). The rules for handling macro definitions in the presence of modules are as follows:
+
+* Each definition and undefinition of a macro is considered to be a distinct entity.
+* Such entities are *visible* if they are from the current submodule or translation unit, or if they were exported from a submodule that has been imported.
+* A ``#define X`` or ``#undef X`` directive *overrides* all definitions of ``X`` that are visible at the point of the directive.
+* A ``#define`` or ``#undef`` directive is *active* if it is visible and no visible directive overrides it.
+* A set of macro directives is *consistent* if it consists of only ``#undef`` directives, or if all ``#define`` directives in the set define the macro name to the same sequence of tokens (following the usual rules for macro redefinitions).
+* If a macro name is used and the set of active directives is not consistent, the program is ill-formed. Otherwise, the (unique) meaning of the macro name is used.
+
+For example, suppose:
+
+* ``<stdio.h>`` defines a macro ``getc`` (and exports its ``#define``)
+* ``<cstdio>`` imports the ``<stdio.h>`` module and undefines the macro (and exports its ``#undef``)
+
+The ``#undef`` overrides the ``#define``, and a source file that imports both modules *in any order* will not see ``getc`` defined as a macro.
+
+Module Map Language
+===================
+
+.. warning::
+
+ The module map language is not currently guaranteed to be stable between major revisions of Clang.
+
+The module map language describes the mapping from header files to the
+logical structure of modules. To enable support for using a library as
+a module, one must write a ``module.modulemap`` file for that library. The
+``module.modulemap`` file is placed alongside the header files themselves,
+and is written in the module map language described below.
+
+.. note::
+ For compatibility with previous releases, if a module map file named
+ ``module.modulemap`` is not found, Clang will also search for a file named
+ ``module.map``. This behavior is deprecated and we plan to eventually
+ remove it.
+
+As an example, the module map file for the C standard library might look a bit like this:
+
+.. parsed-literal::
+
+ module std [system] [extern_c] {
+ module assert {
+ textual header "assert.h"
+ header "bits/assert-decls.h"
+ export *
+ }
+
+ module complex {
+ header "complex.h"
+ export *
+ }
+
+ module ctype {
+ header "ctype.h"
+ export *
+ }
+
+ module errno {
+ header "errno.h"
+ header "sys/errno.h"
+ export *
+ }
+
+ module fenv {
+ header "fenv.h"
+ export *
+ }
+
+ // ...more headers follow...
+ }
+
+Here, the top-level module ``std`` encompasses the whole C standard library. It has a number of submodules containing different parts of the standard library: ``complex`` for complex numbers, ``ctype`` for character types, etc. Each submodule lists one of more headers that provide the contents for that submodule. Finally, the ``export *`` command specifies that anything included by that submodule will be automatically re-exported.
+
+Lexical structure
+-----------------
+Module map files use a simplified form of the C99 lexer, with the same rules for identifiers, tokens, string literals, ``/* */`` and ``//`` comments. The module map language has the following reserved words; all other C identifiers are valid identifiers.
+
+.. parsed-literal::
+
+ ``config_macros`` ``export`` ``private``
+ ``conflict`` ``framework`` ``requires``
+ ``exclude`` ``header`` ``textual``
+ ``explicit`` ``link`` ``umbrella``
+ ``extern`` ``module`` ``use``
+
+Module map file
+---------------
+A module map file consists of a series of module declarations:
+
+.. parsed-literal::
+
+ *module-map-file*:
+ *module-declaration**
+
+Within a module map file, modules are referred to by a *module-id*, which uses periods to separate each part of a module's name:
+
+.. parsed-literal::
+
+ *module-id*:
+ *identifier* ('.' *identifier*)*
+
+Module declaration
+------------------
+A module declaration describes a module, including the headers that contribute to that module, its submodules, and other aspects of the module.
+
+.. parsed-literal::
+
+ *module-declaration*:
+ ``explicit``:sub:`opt` ``framework``:sub:`opt` ``module`` *module-id* *attributes*:sub:`opt` '{' *module-member** '}'
+ ``extern`` ``module`` *module-id* *string-literal*
+
+The *module-id* should consist of only a single *identifier*, which provides the name of the module being defined. Each module shall have a single definition.
+
+The ``explicit`` qualifier can only be applied to a submodule, i.e., a module that is nested within another module. The contents of explicit submodules are only made available when the submodule itself was explicitly named in an import declaration or was re-exported from an imported module.
+
+The ``framework`` qualifier specifies that this module corresponds to a Darwin-style framework. A Darwin-style framework (used primarily on Mac OS X and iOS) is contained entirely in directory ``Name.framework``, where ``Name`` is the name of the framework (and, therefore, the name of the module). That directory has the following layout:
+
+.. parsed-literal::
+
+ Name.framework/
+ Modules/module.modulemap Module map for the framework
+ Headers/ Subdirectory containing framework headers
+ PrivateHeaders/ Subdirectory containing framework private headers
+ Frameworks/ Subdirectory containing embedded frameworks
+ Resources/ Subdirectory containing additional resources
+ Name Symbolic link to the shared library for the framework
+
+The ``system`` attribute specifies that the module is a system module. When a system module is rebuilt, all of the module's headers will be considered system headers, which suppresses warnings. This is equivalent to placing ``#pragma GCC system_header`` in each of the module's headers. The form of attributes is described in the section Attributes_, below.
+
+The ``extern_c`` attribute specifies that the module contains C code that can be used from within C++. When such a module is built for use in C++ code, all of the module's headers will be treated as if they were contained within an implicit ``extern "C"`` block. An import for a module with this attribute can appear within an ``extern "C"`` block. No other restrictions are lifted, however: the module currently cannot be imported within an ``extern "C"`` block in a namespace.
+
+The ``no_undeclared_includes`` attribute specifies that the module can only reach non-modular headers and headers from used modules. Since some headers could be present in more than one search path and map to different modules in each path, this mechanism helps clang to find the right header, i.e., prefer the one for the current module or in a submodule instead of the first usual match in the search paths.
+
+Modules can have a number of different kinds of members, each of which is described below:
+
+.. parsed-literal::
+
+ *module-member*:
+ *requires-declaration*
+ *header-declaration*
+ *umbrella-dir-declaration*
+ *submodule-declaration*
+ *export-declaration*
+ *use-declaration*
+ *link-declaration*
+ *config-macros-declaration*
+ *conflict-declaration*
+
+An extern module references a module defined by the *module-id* in a file given by the *string-literal*. The file can be referenced either by an absolute path or by a path relative to the current map file.
+
+Requires declaration
+~~~~~~~~~~~~~~~~~~~~
+A *requires-declaration* specifies the requirements that an importing translation unit must satisfy to use the module.
+
+.. parsed-literal::
+
+ *requires-declaration*:
+ ``requires`` *feature-list*
+
+ *feature-list*:
+ *feature* (',' *feature*)*
+
+ *feature*:
+ ``!``:sub:`opt` *identifier*
+
+The requirements clause allows specific modules or submodules to specify that they are only accessible with certain language dialects or on certain platforms. The feature list is a set of identifiers, defined below. If any of the features is not available in a given translation unit, that translation unit shall not import the module. When building a module for use by a compilation, submodules requiring unavailable features are ignored. The optional ``!`` indicates that a feature is incompatible with the module.
+
+The following features are defined:
+
+altivec
+ The target supports AltiVec.
+
+blocks
+ The "blocks" language feature is available.
+
+coroutines
+ Support for the coroutines TS is available.
+
+cplusplus
+ C++ support is available.
+
+cplusplus11
+ C++11 support is available.
+
+freestanding
+ A freestanding environment is available.
+
+gnuinlineasm
+ GNU inline ASM is available.
+
+objc
+ Objective-C support is available.
+
+objc_arc
+ Objective-C Automatic Reference Counting (ARC) is available
+
+opencl
+ OpenCL is available
+
+tls
+ Thread local storage is available.
+
+*target feature*
+ A specific target feature (e.g., ``sse4``, ``avx``, ``neon``) is available.
+
+
+**Example:** The ``std`` module can be extended to also include C++ and C++11 headers using a *requires-declaration*:
+
+.. parsed-literal::
+
+ module std {
+ // C standard library...
+
+ module vector {
+ requires cplusplus
+ header "vector"
+ }
+
+ module type_traits {
+ requires cplusplus11
+ header "type_traits"
+ }
+ }
+
+Header declaration
+~~~~~~~~~~~~~~~~~~
+A header declaration specifies that a particular header is associated with the enclosing module.
+
+.. parsed-literal::
+
+ *header-declaration*:
+ ``private``:sub:`opt` ``textual``:sub:`opt` ``header`` *string-literal* *header-attrs*:sub:`opt`
+ ``umbrella`` ``header`` *string-literal* *header-attrs*:sub:`opt`
+ ``exclude`` ``header`` *string-literal* *header-attrs*:sub:`opt`
+
+ *header-attrs*:
+ '{' *header-attr** '}'
+
+ *header-attr*:
+ ``size`` *integer-literal*
+ ``mtime`` *integer-literal*
+
+A header declaration that does not contain ``exclude`` nor ``textual`` specifies a header that contributes to the enclosing module. Specifically, when the module is built, the named header will be parsed and its declarations will be (logically) placed into the enclosing submodule.
+
+A header with the ``umbrella`` specifier is called an umbrella header. An umbrella header includes all of the headers within its directory (and any subdirectories), and is typically used (in the ``#include`` world) to easily access the full API provided by a particular library. With modules, an umbrella header is a convenient shortcut that eliminates the need to write out ``header`` declarations for every library header. A given directory can only contain a single umbrella header.
+
+.. note::
+ Any headers not included by the umbrella header should have
+ explicit ``header`` declarations. Use the
+ ``-Wincomplete-umbrella`` warning option to ask Clang to complain
+ about headers not covered by the umbrella header or the module map.
+
+A header with the ``private`` specifier may not be included from outside the module itself.
+
+A header with the ``textual`` specifier will not be compiled when the module is
+built, and will be textually included if it is named by a ``#include``
+directive. However, it is considered to be part of the module for the purpose
+of checking *use-declaration*\s, and must still be a lexically-valid header
+file. In the future, we intend to pre-tokenize such headers and include the
+token sequence within the prebuilt module representation.
+
+A header with the ``exclude`` specifier is excluded from the module. It will not be included when the module is built, nor will it be considered to be part of the module, even if an ``umbrella`` header or directory would otherwise make it part of the module.
+
+**Example:** The C header ``assert.h`` is an excellent candidate for a textual header, because it is meant to be included multiple times (possibly with different ``NDEBUG`` settings). However, declarations within it should typically be split into a separate modular header.
+
+.. parsed-literal::
+
+ module std [system] {
+ textual header "assert.h"
+ }
+
+A given header shall not be referenced by more than one *header-declaration*.
+
+Two *header-declaration*\s, or a *header-declaration* and a ``#include``, are
+considered to refer to the same file if the paths resolve to the same file
+and the specified *header-attr*\s (if any) match the attributes of that file,
+even if the file is named differently (for instance, by a relative path or
+via symlinks).
+
+.. note::
+ The use of *header-attr*\s avoids the need for Clang to speculatively
+ ``stat`` every header referenced by a module map. It is recommended that
+ *header-attr*\s only be used in machine-generated module maps, to avoid
+ mismatches between attribute values and the corresponding files.
+
+Umbrella directory declaration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+An umbrella directory declaration specifies that all of the headers in the specified directory should be included within the module.
+
+.. parsed-literal::
+
+ *umbrella-dir-declaration*:
+ ``umbrella`` *string-literal*
+
+The *string-literal* refers to a directory. When the module is built, all of the header files in that directory (and its subdirectories) are included in the module.
+
+An *umbrella-dir-declaration* shall not refer to the same directory as the location of an umbrella *header-declaration*. In other words, only a single kind of umbrella can be specified for a given directory.
+
+.. note::
+
+ Umbrella directories are useful for libraries that have a large number of headers but do not have an umbrella header.
+
+
+Submodule declaration
+~~~~~~~~~~~~~~~~~~~~~
+Submodule declarations describe modules that are nested within their enclosing module.
+
+.. parsed-literal::
+
+ *submodule-declaration*:
+ *module-declaration*
+ *inferred-submodule-declaration*
+
+A *submodule-declaration* that is a *module-declaration* is a nested module. If the *module-declaration* has a ``framework`` specifier, the enclosing module shall have a ``framework`` specifier; the submodule's contents shall be contained within the subdirectory ``Frameworks/SubName.framework``, where ``SubName`` is the name of the submodule.
+
+A *submodule-declaration* that is an *inferred-submodule-declaration* describes a set of submodules that correspond to any headers that are part of the module but are not explicitly described by a *header-declaration*.
+
+.. parsed-literal::
+
+ *inferred-submodule-declaration*:
+ ``explicit``:sub:`opt` ``framework``:sub:`opt` ``module`` '*' *attributes*:sub:`opt` '{' *inferred-submodule-member** '}'
+
+ *inferred-submodule-member*:
+ ``export`` '*'
+
+A module containing an *inferred-submodule-declaration* shall have either an umbrella header or an umbrella directory. The headers to which the *inferred-submodule-declaration* applies are exactly those headers included by the umbrella header (transitively) or included in the module because they reside within the umbrella directory (or its subdirectories).
+
+For each header included by the umbrella header or in the umbrella directory that is not named by a *header-declaration*, a module declaration is implicitly generated from the *inferred-submodule-declaration*. The module will:
+
+* Have the same name as the header (without the file extension)
+* Have the ``explicit`` specifier, if the *inferred-submodule-declaration* has the ``explicit`` specifier
+* Have the ``framework`` specifier, if the
+ *inferred-submodule-declaration* has the ``framework`` specifier
+* Have the attributes specified by the \ *inferred-submodule-declaration*
+* Contain a single *header-declaration* naming that header
+* Contain a single *export-declaration* ``export *``, if the \ *inferred-submodule-declaration* contains the \ *inferred-submodule-member* ``export *``
+
+**Example:** If the subdirectory "MyLib" contains the headers ``A.h`` and ``B.h``, then the following module map:
+
+.. parsed-literal::
+
+ module MyLib {
+ umbrella "MyLib"
+ explicit module * {
+ export *
+ }
+ }
+
+is equivalent to the (more verbose) module map:
+
+.. parsed-literal::
+
+ module MyLib {
+ explicit module A {
+ header "A.h"
+ export *
+ }
+
+ explicit module B {
+ header "B.h"
+ export *
+ }
+ }
+
+Export declaration
+~~~~~~~~~~~~~~~~~~
+An *export-declaration* specifies which imported modules will automatically be re-exported as part of a given module's API.
+
+.. parsed-literal::
+
+ *export-declaration*:
+ ``export`` *wildcard-module-id*
+
+ *wildcard-module-id*:
+ *identifier*
+ '*'
+ *identifier* '.' *wildcard-module-id*
+
+The *export-declaration* names a module or a set of modules that will be re-exported to any translation unit that imports the enclosing module. Each imported module that matches the *wildcard-module-id* up to, but not including, the first ``*`` will be re-exported.
+
+**Example:** In the following example, importing ``MyLib.Derived`` also provides the API for ``MyLib.Base``:
+
+.. parsed-literal::
+
+ module MyLib {
+ module Base {
+ header "Base.h"
+ }
+
+ module Derived {
+ header "Derived.h"
+ export Base
+ }
+ }
+
+Note that, if ``Derived.h`` includes ``Base.h``, one can simply use a wildcard export to re-export everything ``Derived.h`` includes:
+
+.. parsed-literal::
+
+ module MyLib {
+ module Base {
+ header "Base.h"
+ }
+
+ module Derived {
+ header "Derived.h"
+ export *
+ }
+ }
+
+.. note::
+
+ The wildcard export syntax ``export *`` re-exports all of the
+ modules that were imported in the actual header file. Because
+ ``#include`` directives are automatically mapped to module imports,
+ ``export *`` provides the same transitive-inclusion behavior
+ provided by the C preprocessor, e.g., importing a given module
+ implicitly imports all of the modules on which it depends.
+ Therefore, liberal use of ``export *`` provides excellent backward
+ compatibility for programs that rely on transitive inclusion (i.e.,
+ all of them).
+
+Use declaration
+~~~~~~~~~~~~~~~
+A *use-declaration* specifies another module that the current top-level module
+intends to use. When the option *-fmodules-decluse* is specified, a module can
+only use other modules that are explicitly specified in this way.
+
+.. parsed-literal::
+
+ *use-declaration*:
+ ``use`` *module-id*
+
+**Example:** In the following example, use of A from C is not declared, so will trigger a warning.
+
+.. parsed-literal::
+
+ module A {
+ header "a.h"
+ }
+
+ module B {
+ header "b.h"
+ }
+
+ module C {
+ header "c.h"
+ use B
+ }
+
+When compiling a source file that implements a module, use the option
+``-fmodule-name=module-id`` to indicate that the source file is logically part
+of that module.
+
+The compiler at present only applies restrictions to the module directly being built.
+
+Link declaration
+~~~~~~~~~~~~~~~~
+A *link-declaration* specifies a library or framework against which a program should be linked if the enclosing module is imported in any translation unit in that program.
+
+.. parsed-literal::
+
+ *link-declaration*:
+ ``link`` ``framework``:sub:`opt` *string-literal*
+
+The *string-literal* specifies the name of the library or framework against which the program should be linked. For example, specifying "clangBasic" would instruct the linker to link with ``-lclangBasic`` for a Unix-style linker.
+
+A *link-declaration* with the ``framework`` specifies that the linker should link against the named framework, e.g., with ``-framework MyFramework``.
+
+.. note::
+
+ Automatic linking with the ``link`` directive is not yet widely
+ implemented, because it requires support from both the object file
+ format and the linker. The notion is similar to Microsoft Visual
+ Studio's ``#pragma comment(lib...)``.
+
+Configuration macros declaration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The *config-macros-declaration* specifies the set of configuration macros that have an effect on the API of the enclosing module.
+
+.. parsed-literal::
+
+ *config-macros-declaration*:
+ ``config_macros`` *attributes*:sub:`opt` *config-macro-list*:sub:`opt`
+
+ *config-macro-list*:
+ *identifier* (',' *identifier*)*
+
+Each *identifier* in the *config-macro-list* specifies the name of a macro. The compiler is required to maintain different variants of the given module for differing definitions of any of the named macros.
+
+A *config-macros-declaration* shall only be present on a top-level module, i.e., a module that is not nested within an enclosing module.
+
+The ``exhaustive`` attribute specifies that the list of macros in the *config-macros-declaration* is exhaustive, meaning that no other macro definition is intended to have an effect on the API of that module.
+
+.. note::
+
+ The ``exhaustive`` attribute implies that any macro definitions
+ for macros not listed as configuration macros should be ignored
+ completely when building the module. As an optimization, the
+ compiler could reduce the number of unique module variants by not
+ considering these non-configuration macros. This optimization is not
+ yet implemented in Clang.
+
+A translation unit shall not import the same module under different definitions of the configuration macros.
+
+.. note::
+
+ Clang implements a weak form of this requirement: the definitions
+ used for configuration macros are fixed based on the definitions
+ provided by the command line. If an import occurs and the definition
+ of any configuration macro has changed, the compiler will produce a
+ warning (under the control of ``-Wconfig-macros``).
+
+**Example:** A logging library might provide different API (e.g., in the form of different definitions for a logging macro) based on the ``NDEBUG`` macro setting:
+
+.. parsed-literal::
+
+ module MyLogger {
+ umbrella header "MyLogger.h"
+ config_macros [exhaustive] NDEBUG
+ }
+
+Conflict declarations
+~~~~~~~~~~~~~~~~~~~~~
+A *conflict-declaration* describes a case where the presence of two different modules in the same translation unit is likely to cause a problem. For example, two modules may provide similar-but-incompatible functionality.
+
+.. parsed-literal::
+
+ *conflict-declaration*:
+ ``conflict`` *module-id* ',' *string-literal*
+
+The *module-id* of the *conflict-declaration* specifies the module with which the enclosing module conflicts. The specified module shall not have been imported in the translation unit when the enclosing module is imported.
+
+The *string-literal* provides a message to be provided as part of the compiler diagnostic when two modules conflict.
+
+.. note::
+
+ Clang emits a warning (under the control of ``-Wmodule-conflict``)
+ when a module conflict is discovered.
+
+**Example:**
+
+.. parsed-literal::
+
+ module Conflicts {
+ explicit module A {
+ header "conflict_a.h"
+ conflict B, "we just don't like B"
+ }
+
+ module B {
+ header "conflict_b.h"
+ }
+ }
+
+
+Attributes
+----------
+Attributes are used in a number of places in the grammar to describe specific behavior of other declarations. The format of attributes is fairly simple.
+
+.. parsed-literal::
+
+ *attributes*:
+ *attribute* *attributes*:sub:`opt`
+
+ *attribute*:
+ '[' *identifier* ']'
+
+Any *identifier* can be used as an attribute, and each declaration specifies what attributes can be applied to it.
+
+Private Module Map Files
+------------------------
+Module map files are typically named ``module.modulemap`` and live
+either alongside the headers they describe or in a parent directory of
+the headers they describe. These module maps typically describe all of
+the API for the library.
+
+However, in some cases, the presence or absence of particular headers
+is used to distinguish between the "public" and "private" APIs of a
+particular library. For example, a library may contain the headers
+``Foo.h`` and ``Foo_Private.h``, providing public and private APIs,
+respectively. Additionally, ``Foo_Private.h`` may only be available on
+some versions of library, and absent in others. One cannot easily
+express this with a single module map file in the library:
+
+.. parsed-literal::
+
+ module Foo {
+ header "Foo.h"
+
+ explicit module Private {
+ header "Foo_Private.h"
+ }
+ }
+
+
+because the header ``Foo_Private.h`` won't always be available. The
+module map file could be customized based on whether
+``Foo_Private.h`` is available or not, but doing so requires custom
+build machinery.
+
+Private module map files, which are named ``module.private.modulemap``
+(or, for backward compatibility, ``module_private.map``), allow one to
+augment the primary module map file with an additional submodule. For
+example, we would split the module map file above into two module map
+files:
+
+.. code-block:: c
+
+ /* module.modulemap */
+ module Foo {
+ header "Foo.h"
+ }
+
+ /* module.private.modulemap */
+ explicit module Foo.Private {
+ header "Foo_Private.h"
+ }
+
+
+When a ``module.private.modulemap`` file is found alongside a
+``module.modulemap`` file, it is loaded after the ``module.modulemap``
+file. In our example library, the ``module.private.modulemap`` file
+would be available when ``Foo_Private.h`` is available, making it
+easier to split a library's public and private APIs along header
+boundaries.
+
+When writing a private module as part of a *framework*, it's recommended that:
+
+* Headers for this module are present in the ``PrivateHeaders``
+ framework subdirectory.
+* The private module is defined as a *submodule* of the public framework (if
+ there's one), similar to how ``Foo.Private`` is defined in the example above.
+* The ``explicit`` keyword should be used to guarantee that its content will
+ only be available when the submodule itself is explicitly named (through a
+ ``@import`` for example).
+
+Modularizing a Platform
+=======================
+To get any benefit out of modules, one needs to introduce module maps for software libraries starting at the bottom of the stack. This typically means introducing a module map covering the operating system's headers and the C standard library headers (in ``/usr/include``, for a Unix system).
+
+The module maps will be written using the `module map language`_, which provides the tools necessary to describe the mapping between headers and modules. Because the set of headers differs from one system to the next, the module map will likely have to be somewhat customized for, e.g., a particular distribution and version of the operating system. Moreover, the system headers themselves may require some modification, if they exhibit any anti-patterns that break modules. Such common patterns are described below.
+
+**Macro-guarded copy-and-pasted definitions**
+ System headers vend core types such as ``size_t`` for users. These types are often needed in a number of system headers, and are almost trivial to write. Hence, it is fairly common to see a definition such as the following copy-and-pasted throughout the headers:
+
+ .. parsed-literal::
+
+ #ifndef _SIZE_T
+ #define _SIZE_T
+ typedef __SIZE_TYPE__ size_t;
+ #endif
+
+ Unfortunately, when modules compiles all of the C library headers together into a single module, only the first actual type definition of ``size_t`` will be visible, and then only in the submodule corresponding to the lucky first header. Any other headers that have copy-and-pasted versions of this pattern will *not* have a definition of ``size_t``. Importing the submodule corresponding to one of those headers will therefore not yield ``size_t`` as part of the API, because it wasn't there when the header was parsed. The fix for this problem is either to pull the copied declarations into a common header that gets included everywhere ``size_t`` is part of the API, or to eliminate the ``#ifndef`` and redefine the ``size_t`` type. The latter works for C++ headers and C11, but will cause an error for non-modules C90/C99, where redefinition of ``typedefs`` is not permitted.
+
+**Conflicting definitions**
+ Different system headers may provide conflicting definitions for various macros, functions, or types. These conflicting definitions don't tend to cause problems in a pre-modules world unless someone happens to include both headers in one translation unit. Since the fix is often simply "don't do that", such problems persist. Modules requires that the conflicting definitions be eliminated or that they be placed in separate modules (the former is generally the better answer).
+
+**Missing includes**
+ Headers are often missing ``#include`` directives for headers that they actually depend on. As with the problem of conflicting definitions, this only affects unlucky users who don't happen to include headers in the right order. With modules, the headers of a particular module will be parsed in isolation, so the module may fail to build if there are missing includes.
+
+**Headers that vend multiple APIs at different times**
+ Some systems have headers that contain a number of different kinds of API definitions, only some of which are made available with a given include. For example, the header may vend ``size_t`` only when the macro ``__need_size_t`` is defined before that header is included, and also vend ``wchar_t`` only when the macro ``__need_wchar_t`` is defined. Such headers are often included many times in a single translation unit, and will have no include guards. There is no sane way to map this header to a submodule. One can either eliminate the header (e.g., by splitting it into separate headers, one per actual API) or simply ``exclude`` it in the module map.
+
+To detect and help address some of these problems, the ``clang-tools-extra`` repository contains a ``modularize`` tool that parses a set of given headers and attempts to detect these problems and produce a report. See the tool's in-source documentation for information on how to check your system or library headers.
+
+Future Directions
+=================
+Modules support is under active development, and there are many opportunities remaining to improve it. Here are a few ideas:
+
+**Detect unused module imports**
+ Unlike with ``#include`` directives, it should be fairly simple to track whether a directly-imported module has ever been used. By doing so, Clang can emit ``unused import`` or ``unused #include`` diagnostics, including Fix-Its to remove the useless imports/includes.
+
+**Fix-Its for missing imports**
+ It's fairly common for one to make use of some API while writing code, only to get a compiler error about "unknown type" or "no function named" because the corresponding header has not been included. Clang can detect such cases and auto-import the required module, but should provide a Fix-It to add the import.
+
+**Improve modularize**
+ The modularize tool is both extremely important (for deployment) and extremely crude. It needs better UI, better detection of problems (especially for C++), and perhaps an assistant mode to help write module maps for you.
+
+Where To Learn More About Modules
+=================================
+The Clang source code provides additional information about modules:
+
+``clang/lib/Headers/module.modulemap``
+ Module map for Clang's compiler-specific header files.
+
+``clang/test/Modules/``
+ Tests specifically related to modules functionality.
+
+``clang/include/clang/Basic/Module.h``
+ The ``Module`` class in this header describes a module, and is used throughout the compiler to implement modules.
+
+``clang/include/clang/Lex/ModuleMap.h``
+ The ``ModuleMap`` class in this header describes the full module map, consisting of all of the module map files that have been parsed, and providing facilities for looking up module maps and mapping between modules and headers (in both directions).
+
+PCHInternals_
+ Information about the serialized AST format used for precompiled headers and modules. The actual implementation is in the ``clangSerialization`` library.
+
+.. [#] Automatic linking against the libraries of modules requires specific linker support, which is not widely available.
+
+.. [#] There are certain anti-patterns that occur in headers, particularly system headers, that cause problems for modules. The section `Modularizing a Platform`_ describes some of them.
+
+.. [#] The second instance is actually a new thread within the current process, not a separate process. However, the original compiler instance is blocked on the execution of this thread.
+
+.. [#] The preprocessing context in which the modules are parsed is actually dependent on the command-line options provided to the compiler, including the language dialect and any ``-D`` options. However, the compiled modules for different command-line options are kept distinct, and any preprocessor directives that occur within the translation unit are ignored. See the section on the `Configuration macros declaration`_ for more information.
+
+.. _PCHInternals: PCHInternals.html
+
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/ObjectiveCLiterals.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/ObjectiveCLiterals.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/ObjectiveCLiterals.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/ObjectiveCLiterals.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,606 @@
+====================
+Objective-C Literals
+====================
+
+Introduction
+============
+
+Three new features were introduced into clang at the same time:
+*NSNumber Literals* provide a syntax for creating ``NSNumber`` from
+scalar literal expressions; *Collection Literals* provide a short-hand
+for creating arrays and dictionaries; *Object Subscripting* provides a
+way to use subscripting with Objective-C objects. Users of Apple
+compiler releases can use these features starting with the Apple LLVM
+Compiler 4.0. Users of open-source LLVM.org compiler releases can use
+these features starting with clang v3.1.
+
+These language additions simplify common Objective-C programming
+patterns, make programs more concise, and improve the safety of
+container creation.
+
+This document describes how the features are implemented in clang, and
+how to use them in your own programs.
+
+NSNumber Literals
+=================
+
+The framework class ``NSNumber`` is used to wrap scalar values inside
+objects: signed and unsigned integers (``char``, ``short``, ``int``,
+``long``, ``long long``), floating point numbers (``float``,
+``double``), and boolean values (``BOOL``, C++ ``bool``). Scalar values
+wrapped in objects are also known as *boxed* values.
+
+In Objective-C, any character, numeric or boolean literal prefixed with
+the ``'@'`` character will evaluate to a pointer to an ``NSNumber``
+object initialized with that value. C's type suffixes may be used to
+control the size of numeric literals.
+
+Examples
+--------
+
+The following program illustrates the rules for ``NSNumber`` literals:
+
+.. code-block:: objc
+
+ void main(int argc, const char *argv[]) {
+ // character literals.
+ NSNumber *theLetterZ = @'Z'; // equivalent to [NSNumber numberWithChar:'Z']
+
+ // integral literals.
+ NSNumber *fortyTwo = @42; // equivalent to [NSNumber numberWithInt:42]
+ NSNumber *fortyTwoUnsigned = @42U; // equivalent to [NSNumber numberWithUnsignedInt:42U]
+ NSNumber *fortyTwoLong = @42L; // equivalent to [NSNumber numberWithLong:42L]
+ NSNumber *fortyTwoLongLong = @42LL; // equivalent to [NSNumber numberWithLongLong:42LL]
+
+ // floating point literals.
+ NSNumber *piFloat = @3.141592654F; // equivalent to [NSNumber numberWithFloat:3.141592654F]
+ NSNumber *piDouble = @3.1415926535; // equivalent to [NSNumber numberWithDouble:3.1415926535]
+
+ // BOOL literals.
+ NSNumber *yesNumber = @YES; // equivalent to [NSNumber numberWithBool:YES]
+ NSNumber *noNumber = @NO; // equivalent to [NSNumber numberWithBool:NO]
+
+ #ifdef __cplusplus
+ NSNumber *trueNumber = @true; // equivalent to [NSNumber numberWithBool:(BOOL)true]
+ NSNumber *falseNumber = @false; // equivalent to [NSNumber numberWithBool:(BOOL)false]
+ #endif
+ }
+
+Discussion
+----------
+
+NSNumber literals only support literal scalar values after the ``'@'``.
+Consequently, ``@INT_MAX`` works, but ``@INT_MIN`` does not, because
+they are defined like this:
+
+.. code-block:: objc
+
+ #define INT_MAX 2147483647 /* max value for an int */
+ #define INT_MIN (-2147483647-1) /* min value for an int */
+
+The definition of ``INT_MIN`` is not a simple literal, but a
+parenthesized expression. Parenthesized expressions are supported using
+the `boxed expression <#objc_boxed_expressions>`_ syntax, which is
+described in the next section.
+
+Because ``NSNumber`` does not currently support wrapping ``long double``
+values, the use of a ``long double NSNumber`` literal (e.g.
+``@123.23L``) will be rejected by the compiler.
+
+Previously, the ``BOOL`` type was simply a typedef for ``signed char``,
+and ``YES`` and ``NO`` were macros that expand to ``(BOOL)1`` and
+``(BOOL)0`` respectively. To support ``@YES`` and ``@NO`` expressions,
+these macros are now defined using new language keywords in
+``<objc/objc.h>``:
+
+.. code-block:: objc
+
+ #if __has_feature(objc_bool)
+ #define YES __objc_yes
+ #define NO __objc_no
+ #else
+ #define YES ((BOOL)1)
+ #define NO ((BOOL)0)
+ #endif
+
+The compiler implicitly converts ``__objc_yes`` and ``__objc_no`` to
+``(BOOL)1`` and ``(BOOL)0``. The keywords are used to disambiguate
+``BOOL`` and integer literals.
+
+Objective-C++ also supports ``@true`` and ``@false`` expressions, which
+are equivalent to ``@YES`` and ``@NO``.
+
+Boxed Expressions
+=================
+
+Objective-C provides a new syntax for boxing C expressions:
+
+.. code-block:: objc
+
+ @( <expression> )
+
+Expressions of scalar (numeric, enumerated, BOOL), C string pointer
+and some C structures (via NSValue) are supported:
+
+.. code-block:: objc
+
+ // numbers.
+ NSNumber *smallestInt = @(-INT_MAX - 1); // [NSNumber numberWithInt:(-INT_MAX - 1)]
+ NSNumber *piOverTwo = @(M_PI / 2); // [NSNumber numberWithDouble:(M_PI / 2)]
+
+ // enumerated types.
+ typedef enum { Red, Green, Blue } Color;
+ NSNumber *favoriteColor = @(Green); // [NSNumber numberWithInt:((int)Green)]
+
+ // strings.
+ NSString *path = @(getenv("PATH")); // [NSString stringWithUTF8String:(getenv("PATH"))]
+ NSArray *pathComponents = [path componentsSeparatedByString:@":"];
+
+ // structs.
+ NSValue *center = @(view.center); // Point p = view.center;
+ // [NSValue valueWithBytes:&p objCType:@encode(Point)];
+ NSValue *frame = @(view.frame); // Rect r = view.frame;
+ // [NSValue valueWithBytes:&r objCType:@encode(Rect)];
+
+Boxed Enums
+-----------
+
+Cocoa frameworks frequently define constant values using *enums.*
+Although enum values are integral, they may not be used directly as
+boxed literals (this avoids conflicts with future ``'@'``-prefixed
+Objective-C keywords). Instead, an enum value must be placed inside a
+boxed expression. The following example demonstrates configuring an
+``AVAudioRecorder`` using a dictionary that contains a boxed enumeration
+value:
+
+.. code-block:: objc
+
+ enum {
+ AVAudioQualityMin = 0,
+ AVAudioQualityLow = 0x20,
+ AVAudioQualityMedium = 0x40,
+ AVAudioQualityHigh = 0x60,
+ AVAudioQualityMax = 0x7F
+ };
+
+ - (AVAudioRecorder *)recordToFile:(NSURL *)fileURL {
+ NSDictionary *settings = @{ AVEncoderAudioQualityKey : @(AVAudioQualityMax) };
+ return [[AVAudioRecorder alloc] initWithURL:fileURL settings:settings error:NULL];
+ }
+
+The expression ``@(AVAudioQualityMax)`` converts ``AVAudioQualityMax``
+to an integer type, and boxes the value accordingly. If the enum has a
+:ref:`fixed underlying type <objc-fixed-enum>` as in:
+
+.. code-block:: objc
+
+ typedef enum : unsigned char { Red, Green, Blue } Color;
+ NSNumber *red = @(Red), *green = @(Green), *blue = @(Blue); // => [NSNumber numberWithUnsignedChar:]
+
+then the fixed underlying type will be used to select the correct
+``NSNumber`` creation method.
+
+Boxing a value of enum type will result in a ``NSNumber`` pointer with a
+creation method according to the underlying type of the enum, which can
+be a :ref:`fixed underlying type <objc-fixed-enum>`
+or a compiler-defined integer type capable of representing the values of
+all the members of the enumeration:
+
+.. code-block:: objc
+
+ typedef enum : unsigned char { Red, Green, Blue } Color;
+ Color col = Red;
+ NSNumber *nsCol = @(col); // => [NSNumber numberWithUnsignedChar:]
+
+Boxed C Strings
+---------------
+
+A C string literal prefixed by the ``'@'`` token denotes an ``NSString``
+literal in the same way a numeric literal prefixed by the ``'@'`` token
+denotes an ``NSNumber`` literal. When the type of the parenthesized
+expression is ``(char *)`` or ``(const char *)``, the result of the
+boxed expression is a pointer to an ``NSString`` object containing
+equivalent character data, which is assumed to be '\\0'-terminated and
+UTF-8 encoded. The following example converts C-style command line
+arguments into ``NSString`` objects.
+
+.. code-block:: objc
+
+ // Partition command line arguments into positional and option arguments.
+ NSMutableArray *args = [NSMutableArray new];
+ NSMutableDictionary *options = [NSMutableDictionary new];
+ while (--argc) {
+ const char *arg = *++argv;
+ if (strncmp(arg, "--", 2) == 0) {
+ options[@(arg + 2)] = @(*++argv); // --key value
+ } else {
+ [args addObject:@(arg)]; // positional argument
+ }
+ }
+
+As with all C pointers, character pointer expressions can involve
+arbitrary pointer arithmetic, therefore programmers must ensure that the
+character data is valid. Passing ``NULL`` as the character pointer will
+raise an exception at runtime. When possible, the compiler will reject
+``NULL`` character pointers used in boxed expressions.
+
+Boxed C Structures
+------------------
+
+Boxed expressions support construction of NSValue objects.
+It said that C structures can be used, the only requirement is:
+structure should be marked with ``objc_boxable`` attribute.
+To support older version of frameworks and/or third-party libraries
+you may need to add the attribute via ``typedef``.
+
+.. code-block:: objc
+
+ struct __attribute__((objc_boxable)) Point {
+ // ...
+ };
+
+ typedef struct __attribute__((objc_boxable)) _Size {
+ // ...
+ } Size;
+
+ typedef struct _Rect {
+ // ...
+ } Rect;
+
+ struct Point p;
+ NSValue *point = @(p); // ok
+ Size s;
+ NSValue *size = @(s); // ok
+
+ Rect r;
+ NSValue *bad_rect = @(r); // error
+
+ typedef struct __attribute__((objc_boxable)) _Rect Rect;
+
+ NSValue *good_rect = @(r); // ok
+
+
+Container Literals
+==================
+
+Objective-C now supports a new expression syntax for creating immutable
+array and dictionary container objects.
+
+Examples
+--------
+
+Immutable array expression:
+
+.. code-block:: objc
+
+ NSArray *array = @[ @"Hello", NSApp, [NSNumber numberWithInt:42] ];
+
+This creates an ``NSArray`` with 3 elements. The comma-separated
+sub-expressions of an array literal can be any Objective-C object
+pointer typed expression.
+
+Immutable dictionary expression:
+
+.. code-block:: objc
+
+ NSDictionary *dictionary = @{
+ @"name" : NSUserName(),
+ @"date" : [NSDate date],
+ @"processInfo" : [NSProcessInfo processInfo]
+ };
+
+This creates an ``NSDictionary`` with 3 key/value pairs. Value
+sub-expressions of a dictionary literal must be Objective-C object
+pointer typed, as in array literals. Key sub-expressions must be of an
+Objective-C object pointer type that implements the
+``<NSCopying>`` protocol.
+
+Discussion
+----------
+
+Neither keys nor values can have the value ``nil`` in containers. If the
+compiler can prove that a key or value is ``nil`` at compile time, then
+a warning will be emitted. Otherwise, a runtime error will occur.
+
+Using array and dictionary literals is safer than the variadic creation
+forms commonly in use today. Array literal expressions expand to calls
+to ``+[NSArray arrayWithObjects:count:]``, which validates that all
+objects are non-``nil``. The variadic form,
+``+[NSArray arrayWithObjects:]`` uses ``nil`` as an argument list
+terminator, which can lead to malformed array objects. Dictionary
+literals are similarly created with
+``+[NSDictionary dictionaryWithObjects:forKeys:count:]`` which validates
+all objects and keys, unlike
+``+[NSDictionary dictionaryWithObjectsAndKeys:]`` which also uses a
+``nil`` parameter as an argument list terminator.
+
+Object Subscripting
+===================
+
+Objective-C object pointer values can now be used with C's subscripting
+operator.
+
+Examples
+--------
+
+The following code demonstrates the use of object subscripting syntax
+with ``NSMutableArray`` and ``NSMutableDictionary`` objects:
+
+.. code-block:: objc
+
+ NSMutableArray *array = ...;
+ NSUInteger idx = ...;
+ id newObject = ...;
+ id oldObject = array[idx];
+ array[idx] = newObject; // replace oldObject with newObject
+
+ NSMutableDictionary *dictionary = ...;
+ NSString *key = ...;
+ oldObject = dictionary[key];
+ dictionary[key] = newObject; // replace oldObject with newObject
+
+The next section explains how subscripting expressions map to accessor
+methods.
+
+Subscripting Methods
+--------------------
+
+Objective-C supports two kinds of subscript expressions: *array-style*
+subscript expressions use integer typed subscripts; *dictionary-style*
+subscript expressions use Objective-C object pointer typed subscripts.
+Each type of subscript expression is mapped to a message send using a
+predefined selector. The advantage of this design is flexibility: class
+designers are free to introduce subscripting by declaring methods or by
+adopting protocols. Moreover, because the method names are selected by
+the type of the subscript, an object can be subscripted using both array
+and dictionary styles.
+
+Array-Style Subscripting
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+When the subscript operand has an integral type, the expression is
+rewritten to use one of two different selectors, depending on whether
+the element is being read or written. When an expression reads an
+element using an integral index, as in the following example:
+
+.. code-block:: objc
+
+ NSUInteger idx = ...;
+ id value = object[idx];
+
+it is translated into a call to ``objectAtIndexedSubscript:``
+
+.. code-block:: objc
+
+ id value = [object objectAtIndexedSubscript:idx];
+
+When an expression writes an element using an integral index:
+
+.. code-block:: objc
+
+ object[idx] = newValue;
+
+it is translated to a call to ``setObject:atIndexedSubscript:``
+
+.. code-block:: objc
+
+ [object setObject:newValue atIndexedSubscript:idx];
+
+These message sends are then type-checked and performed just like
+explicit message sends. The method used for objectAtIndexedSubscript:
+must be declared with an argument of integral type and a return value of
+some Objective-C object pointer type. The method used for
+setObject:atIndexedSubscript: must be declared with its first argument
+having some Objective-C pointer type and its second argument having
+integral type.
+
+The meaning of indexes is left up to the declaring class. The compiler
+will coerce the index to the appropriate argument type of the method it
+uses for type-checking. For an instance of ``NSArray``, reading an
+element using an index outside the range ``[0, array.count)`` will raise
+an exception. For an instance of ``NSMutableArray``, assigning to an
+element using an index within this range will replace that element, but
+assigning to an element using an index outside this range will raise an
+exception; no syntax is provided for inserting, appending, or removing
+elements for mutable arrays.
+
+A class need not declare both methods in order to take advantage of this
+language feature. For example, the class ``NSArray`` declares only
+``objectAtIndexedSubscript:``, so that assignments to elements will fail
+to type-check; moreover, its subclass ``NSMutableArray`` declares
+``setObject:atIndexedSubscript:``.
+
+Dictionary-Style Subscripting
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When the subscript operand has an Objective-C object pointer type, the
+expression is rewritten to use one of two different selectors, depending
+on whether the element is being read from or written to. When an
+expression reads an element using an Objective-C object pointer
+subscript operand, as in the following example:
+
+.. code-block:: objc
+
+ id key = ...;
+ id value = object[key];
+
+it is translated into a call to the ``objectForKeyedSubscript:`` method:
+
+.. code-block:: objc
+
+ id value = [object objectForKeyedSubscript:key];
+
+When an expression writes an element using an Objective-C object pointer
+subscript:
+
+.. code-block:: objc
+
+ object[key] = newValue;
+
+it is translated to a call to ``setObject:forKeyedSubscript:``
+
+.. code-block:: objc
+
+ [object setObject:newValue forKeyedSubscript:key];
+
+The behavior of ``setObject:forKeyedSubscript:`` is class-specific; but
+in general it should replace an existing value if one is already
+associated with a key, otherwise it should add a new value for the key.
+No syntax is provided for removing elements from mutable dictionaries.
+
+Discussion
+----------
+
+An Objective-C subscript expression occurs when the base operand of the
+C subscript operator has an Objective-C object pointer type. Since this
+potentially collides with pointer arithmetic on the value, these
+expressions are only supported under the modern Objective-C runtime,
+which categorically forbids such arithmetic.
+
+Currently, only subscripts of integral or Objective-C object pointer
+type are supported. In C++, a class type can be used if it has a single
+conversion function to an integral or Objective-C pointer type, in which
+case that conversion is applied and analysis continues as appropriate.
+Otherwise, the expression is ill-formed.
+
+An Objective-C object subscript expression is always an l-value. If the
+expression appears on the left-hand side of a simple assignment operator
+(=), the element is written as described below. If the expression
+appears on the left-hand side of a compound assignment operator (e.g.
++=), the program is ill-formed, because the result of reading an element
+is always an Objective-C object pointer and no binary operators are
+legal on such pointers. If the expression appears in any other position,
+the element is read as described below. It is an error to take the
+address of a subscript expression, or (in C++) to bind a reference to
+it.
+
+Programs can use object subscripting with Objective-C object pointers of
+type ``id``. Normal dynamic message send rules apply; the compiler must
+see *some* declaration of the subscripting methods, and will pick the
+declaration seen first.
+
+Caveats
+=======
+
+Objects created using the literal or boxed expression syntax are not
+guaranteed to be uniqued by the runtime, but nor are they guaranteed to
+be newly-allocated. As such, the result of performing direct comparisons
+against the location of an object literal (using ``==``, ``!=``, ``<``,
+``<=``, ``>``, or ``>=``) is not well-defined. This is usually a simple
+mistake in code that intended to call the ``isEqual:`` method (or the
+``compare:`` method).
+
+This caveat applies to compile-time string literals as well.
+Historically, string literals (using the ``@"..."`` syntax) have been
+uniqued across translation units during linking. This is an
+implementation detail of the compiler and should not be relied upon. If
+you are using such code, please use global string constants instead
+(``NSString * const MyConst = @"..."``) or use ``isEqual:``.
+
+Grammar Additions
+=================
+
+To support the new syntax described above, the Objective-C
+``@``-expression grammar has the following new productions:
+
+::
+
+ objc-at-expression : '@' (string-literal | encode-literal | selector-literal | protocol-literal | object-literal)
+ ;
+
+ object-literal : ('+' | '-')? numeric-constant
+ | character-constant
+ | boolean-constant
+ | array-literal
+ | dictionary-literal
+ ;
+
+ boolean-constant : '__objc_yes' | '__objc_no' | 'true' | 'false' /* boolean keywords. */
+ ;
+
+ array-literal : '[' assignment-expression-list ']'
+ ;
+
+ assignment-expression-list : assignment-expression (',' assignment-expression-list)?
+ | /* empty */
+ ;
+
+ dictionary-literal : '{' key-value-list '}'
+ ;
+
+ key-value-list : key-value-pair (',' key-value-list)?
+ | /* empty */
+ ;
+
+ key-value-pair : assignment-expression ':' assignment-expression
+ ;
+
+Note: ``@true`` and ``@false`` are only supported in Objective-C++.
+
+Availability Checks
+===================
+
+Programs test for the new features by using clang's \_\_has\_feature
+checks. Here are examples of their use:
+
+.. code-block:: objc
+
+ #if __has_feature(objc_array_literals)
+ // new way.
+ NSArray *elements = @[ @"H", @"He", @"O", @"C" ];
+ #else
+ // old way (equivalent).
+ id objects[] = { @"H", @"He", @"O", @"C" };
+ NSArray *elements = [NSArray arrayWithObjects:objects count:4];
+ #endif
+
+ #if __has_feature(objc_dictionary_literals)
+ // new way.
+ NSDictionary *masses = @{ @"H" : @1.0078, @"He" : @4.0026, @"O" : @15.9990, @"C" : @12.0096 };
+ #else
+ // old way (equivalent).
+ id keys[] = { @"H", @"He", @"O", @"C" };
+ id values[] = { [NSNumber numberWithDouble:1.0078], [NSNumber numberWithDouble:4.0026],
+ [NSNumber numberWithDouble:15.9990], [NSNumber numberWithDouble:12.0096] };
+ NSDictionary *masses = [NSDictionary dictionaryWithObjects:objects forKeys:keys count:4];
+ #endif
+
+ #if __has_feature(objc_subscripting)
+ NSUInteger i, count = elements.count;
+ for (i = 0; i < count; ++i) {
+ NSString *element = elements[i];
+ NSNumber *mass = masses[element];
+ NSLog(@"the mass of %@ is %@", element, mass);
+ }
+ #else
+ NSUInteger i, count = [elements count];
+ for (i = 0; i < count; ++i) {
+ NSString *element = [elements objectAtIndex:i];
+ NSNumber *mass = [masses objectForKey:element];
+ NSLog(@"the mass of %@ is %@", element, mass);
+ }
+ #endif
+
+ #if __has_attribute(objc_boxable)
+ typedef struct __attribute__((objc_boxable)) _Rect Rect;
+ #endif
+
+ #if __has_feature(objc_boxed_nsvalue_expressions)
+ CABasicAnimation animation = [CABasicAnimation animationWithKeyPath:@"position"];
+ animation.fromValue = @(layer.position);
+ animation.toValue = @(newPosition);
+ [layer addAnimation:animation forKey:@"move"];
+ #else
+ CABasicAnimation animation = [CABasicAnimation animationWithKeyPath:@"position"];
+ animation.fromValue = [NSValue valueWithCGPoint:layer.position];
+ animation.toValue = [NSValue valueWithCGPoint:newPosition];
+ [layer addAnimation:animation forKey:@"move"];
+ #endif
+
+Code can use also ``__has_feature(objc_bool)`` to check for the
+availability of numeric literals support. This checks for the new
+``__objc_yes / __objc_no`` keywords, which enable the use of
+``@YES / @NO`` literals.
+
+To check whether boxed expressions are supported, use
+``__has_feature(objc_boxed_expressions)`` feature macro.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/PCHInternals.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/PCHInternals.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/PCHInternals.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/PCHInternals.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,571 @@
+========================================
+Precompiled Header and Modules Internals
+========================================
+
+.. contents::
+ :local:
+
+This document describes the design and implementation of Clang's precompiled
+headers (PCH) and modules. If you are interested in the end-user view, please
+see the :ref:`User's Manual <usersmanual-precompiled-headers>`.
+
+Using Precompiled Headers with ``clang``
+----------------------------------------
+
+The Clang compiler frontend, ``clang -cc1``, supports two command line options
+for generating and using PCH files.
+
+To generate PCH files using ``clang -cc1``, use the option `-emit-pch`:
+
+.. code-block:: bash
+
+ $ clang -cc1 test.h -emit-pch -o test.h.pch
+
+This option is transparently used by ``clang`` when generating PCH files. The
+resulting PCH file contains the serialized form of the compiler's internal
+representation after it has completed parsing and semantic analysis. The PCH
+file can then be used as a prefix header with the `-include-pch`
+option:
+
+.. code-block:: bash
+
+ $ clang -cc1 -include-pch test.h.pch test.c -o test.s
+
+Design Philosophy
+-----------------
+
+Precompiled headers are meant to improve overall compile times for projects, so
+the design of precompiled headers is entirely driven by performance concerns.
+The use case for precompiled headers is relatively simple: when there is a
+common set of headers that is included in nearly every source file in the
+project, we *precompile* that bundle of headers into a single precompiled
+header (PCH file). Then, when compiling the source files in the project, we
+load the PCH file first (as a prefix header), which acts as a stand-in for that
+bundle of headers.
+
+A precompiled header implementation improves performance when:
+
+* Loading the PCH file is significantly faster than re-parsing the bundle of
+ headers stored within the PCH file. Thus, a precompiled header design
+ attempts to minimize the cost of reading the PCH file. Ideally, this cost
+ should not vary with the size of the precompiled header file.
+
+* The cost of generating the PCH file initially is not so large that it
+ counters the per-source-file performance improvement due to eliminating the
+ need to parse the bundled headers in the first place. This is particularly
+ important on multi-core systems, because PCH file generation serializes the
+ build when all compilations require the PCH file to be up-to-date.
+
+Modules, as implemented in Clang, use the same mechanisms as precompiled
+headers to save a serialized AST file (one per module) and use those AST
+modules. From an implementation standpoint, modules are a generalization of
+precompiled headers, lifting a number of restrictions placed on precompiled
+headers. In particular, there can only be one precompiled header and it must
+be included at the beginning of the translation unit. The extensions to the
+AST file format required for modules are discussed in the section on
+:ref:`modules <pchinternals-modules>`.
+
+Clang's AST files are designed with a compact on-disk representation, which
+minimizes both creation time and the time required to initially load the AST
+file. The AST file itself contains a serialized representation of Clang's
+abstract syntax trees and supporting data structures, stored using the same
+compressed bitstream as `LLVM's bitcode file format
+<http://llvm.org/docs/BitCodeFormat.html>`_.
+
+Clang's AST files are loaded "lazily" from disk. When an AST file is initially
+loaded, Clang reads only a small amount of data from the AST file to establish
+where certain important data structures are stored. The amount of data read in
+this initial load is independent of the size of the AST file, such that a
+larger AST file does not lead to longer AST load times. The actual header data
+in the AST file --- macros, functions, variables, types, etc. --- is loaded
+only when it is referenced from the user's code, at which point only that
+entity (and those entities it depends on) are deserialized from the AST file.
+With this approach, the cost of using an AST file for a translation unit is
+proportional to the amount of code actually used from the AST file, rather than
+being proportional to the size of the AST file itself.
+
+When given the `-print-stats` option, Clang produces statistics
+describing how much of the AST file was actually loaded from disk. For a
+simple "Hello, World!" program that includes the Apple ``Cocoa.h`` header
+(which is built as a precompiled header), this option illustrates how little of
+the actual precompiled header is required:
+
+.. code-block:: none
+
+ *** AST File Statistics:
+ 895/39981 source location entries read (2.238563%)
+ 19/15315 types read (0.124061%)
+ 20/82685 declarations read (0.024188%)
+ 154/58070 identifiers read (0.265197%)
+ 0/7260 selectors read (0.000000%)
+ 0/30842 statements read (0.000000%)
+ 4/8400 macros read (0.047619%)
+ 1/4995 lexical declcontexts read (0.020020%)
+ 0/4413 visible declcontexts read (0.000000%)
+ 0/7230 method pool entries read (0.000000%)
+ 0 method pool misses
+
+For this small program, only a tiny fraction of the source locations, types,
+declarations, identifiers, and macros were actually deserialized from the
+precompiled header. These statistics can be useful to determine whether the
+AST file implementation can be improved by making more of the implementation
+lazy.
+
+Precompiled headers can be chained. When you create a PCH while including an
+existing PCH, Clang can create the new PCH by referencing the original file and
+only writing the new data to the new file. For example, you could create a PCH
+out of all the headers that are very commonly used throughout your project, and
+then create a PCH for every single source file in the project that includes the
+code that is specific to that file, so that recompiling the file itself is very
+fast, without duplicating the data from the common headers for every file. The
+mechanisms behind chained precompiled headers are discussed in a :ref:`later
+section <pchinternals-chained>`.
+
+AST File Contents
+-----------------
+
+An AST file produced by clang is an object file container with a ``clangast``
+(COFF) or ``__clangast`` (ELF and Mach-O) section containing the serialized AST.
+Other target-specific sections in the object file container are used to hold
+debug information for the data types defined in the AST. Tools built on top of
+libclang that do not need debug information may also produce raw AST files that
+only contain the serialized AST.
+
+The ``clangast`` section is organized into several different blocks, each of
+which contains the serialized representation of a part of Clang's internal
+representation. Each of the blocks corresponds to either a block or a record
+within `LLVM's bitstream format <http://llvm.org/docs/BitCodeFormat.html>`_.
+The contents of each of these logical blocks are described below.
+
+.. image:: PCHLayout.png
+
+The ``llvm-objdump`` utility provides a ``-raw-clang-ast`` option to extract the
+binary contents of the AST section from an object file container.
+
+The `llvm-bcanalyzer <http://llvm.org/docs/CommandGuide/llvm-bcanalyzer.html>`_
+utility can be used to examine the actual structure of the bitstream for the AST
+section. This information can be used both to help understand the structure of
+the AST section and to isolate areas where the AST representation can still be
+optimized, e.g., through the introduction of abbreviations.
+
+
+Metadata Block
+^^^^^^^^^^^^^^
+
+The metadata block contains several records that provide information about how
+the AST file was built. This metadata is primarily used to validate the use of
+an AST file. For example, a precompiled header built for a 32-bit x86 target
+cannot be used when compiling for a 64-bit x86 target. The metadata block
+contains information about:
+
+Language options
+ Describes the particular language dialect used to compile the AST file,
+ including major options (e.g., Objective-C support) and more minor options
+ (e.g., support for "``//``" comments). The contents of this record correspond to
+ the ``LangOptions`` class.
+
+Target architecture
+ The target triple that describes the architecture, platform, and ABI for
+ which the AST file was generated, e.g., ``i386-apple-darwin9``.
+
+AST version
+ The major and minor version numbers of the AST file format. Changes in the
+ minor version number should not affect backward compatibility, while changes
+ in the major version number imply that a newer compiler cannot read an older
+ precompiled header (and vice-versa).
+
+Original file name
+ The full path of the header that was used to generate the AST file.
+
+Predefines buffer
+ Although not explicitly stored as part of the metadata, the predefines buffer
+ is used in the validation of the AST file. The predefines buffer itself
+ contains code generated by the compiler to initialize the preprocessor state
+ according to the current target, platform, and command-line options. For
+ example, the predefines buffer will contain "``#define __STDC__ 1``" when we
+ are compiling C without Microsoft extensions. The predefines buffer itself
+ is stored within the :ref:`pchinternals-sourcemgr`, but its contents are
+ verified along with the rest of the metadata.
+
+A chained PCH file (that is, one that references another PCH) and a module
+(which may import other modules) have additional metadata containing the list
+of all AST files that this AST file depends on. Each of those files will be
+loaded along with this AST file.
+
+For chained precompiled headers, the language options, target architecture and
+predefines buffer data is taken from the end of the chain, since they have to
+match anyway.
+
+.. _pchinternals-sourcemgr:
+
+Source Manager Block
+^^^^^^^^^^^^^^^^^^^^
+
+The source manager block contains the serialized representation of Clang's
+:ref:`SourceManager <SourceManager>` class, which handles the mapping from
+source locations (as represented in Clang's abstract syntax tree) into actual
+column/line positions within a source file or macro instantiation. The AST
+file's representation of the source manager also includes information about all
+of the headers that were (transitively) included when building the AST file.
+
+The bulk of the source manager block is dedicated to information about the
+various files, buffers, and macro instantiations into which a source location
+can refer. Each of these is referenced by a numeric "file ID", which is a
+unique number (allocated starting at 1) stored in the source location. Clang
+serializes the information for each kind of file ID, along with an index that
+maps file IDs to the position within the AST file where the information about
+that file ID is stored. The data associated with a file ID is loaded only when
+required by the front end, e.g., to emit a diagnostic that includes a macro
+instantiation history inside the header itself.
+
+The source manager block also contains information about all of the headers
+that were included when building the AST file. This includes information about
+the controlling macro for the header (e.g., when the preprocessor identified
+that the contents of the header dependent on a macro like
+``LLVM_CLANG_SOURCEMANAGER_H``).
+
+.. _pchinternals-preprocessor:
+
+Preprocessor Block
+^^^^^^^^^^^^^^^^^^
+
+The preprocessor block contains the serialized representation of the
+preprocessor. Specifically, it contains all of the macros that have been
+defined by the end of the header used to build the AST file, along with the
+token sequences that comprise each macro. The macro definitions are only read
+from the AST file when the name of the macro first occurs in the program. This
+lazy loading of macro definitions is triggered by lookups into the
+:ref:`identifier table <pchinternals-ident-table>`.
+
+.. _pchinternals-types:
+
+Types Block
+^^^^^^^^^^^
+
+The types block contains the serialized representation of all of the types
+referenced in the translation unit. Each Clang type node (``PointerType``,
+``FunctionProtoType``, etc.) has a corresponding record type in the AST file.
+When types are deserialized from the AST file, the data within the record is
+used to reconstruct the appropriate type node using the AST context.
+
+Each type has a unique type ID, which is an integer that uniquely identifies
+that type. Type ID 0 represents the NULL type, type IDs less than
+``NUM_PREDEF_TYPE_IDS`` represent predefined types (``void``, ``float``, etc.),
+while other "user-defined" type IDs are assigned consecutively from
+``NUM_PREDEF_TYPE_IDS`` upward as the types are encountered. The AST file has
+an associated mapping from the user-defined types block to the location within
+the types block where the serialized representation of that type resides,
+enabling lazy deserialization of types. When a type is referenced from within
+the AST file, that reference is encoded using the type ID shifted left by 3
+bits. The lower three bits are used to represent the ``const``, ``volatile``,
+and ``restrict`` qualifiers, as in Clang's :ref:`QualType <QualType>` class.
+
+.. _pchinternals-decls:
+
+Declarations Block
+^^^^^^^^^^^^^^^^^^
+
+The declarations block contains the serialized representation of all of the
+declarations referenced in the translation unit. Each Clang declaration node
+(``VarDecl``, ``FunctionDecl``, etc.) has a corresponding record type in the
+AST file. When declarations are deserialized from the AST file, the data
+within the record is used to build and populate a new instance of the
+corresponding ``Decl`` node. As with types, each declaration node has a
+numeric ID that is used to refer to that declaration within the AST file. In
+addition, a lookup table provides a mapping from that numeric ID to the offset
+within the precompiled header where that declaration is described.
+
+Declarations in Clang's abstract syntax trees are stored hierarchically. At
+the top of the hierarchy is the translation unit (``TranslationUnitDecl``),
+which contains all of the declarations in the translation unit but is not
+actually written as a specific declaration node. Its child declarations (such
+as functions or struct types) may also contain other declarations inside them,
+and so on. Within Clang, each declaration is stored within a :ref:`declaration
+context <DeclContext>`, as represented by the ``DeclContext`` class.
+Declaration contexts provide the mechanism to perform name lookup within a
+given declaration (e.g., find the member named ``x`` in a structure) and
+iterate over the declarations stored within a context (e.g., iterate over all
+of the fields of a structure for structure layout).
+
+In Clang's AST file format, deserializing a declaration that is a
+``DeclContext`` is a separate operation from deserializing all of the
+declarations stored within that declaration context. Therefore, Clang will
+deserialize the translation unit declaration without deserializing the
+declarations within that translation unit. When required, the declarations
+stored within a declaration context will be deserialized. There are two
+representations of the declarations within a declaration context, which
+correspond to the name-lookup and iteration behavior described above:
+
+* When the front end performs name lookup to find a name ``x`` within a given
+ declaration context (for example, during semantic analysis of the expression
+ ``p->x``, where ``p``'s type is defined in the precompiled header), Clang
+ refers to an on-disk hash table that maps from the names within that
+ declaration context to the declaration IDs that represent each visible
+ declaration with that name. The actual declarations will then be
+ deserialized to provide the results of name lookup.
+* When the front end performs iteration over all of the declarations within a
+ declaration context, all of those declarations are immediately
+ de-serialized. For large declaration contexts (e.g., the translation unit),
+ this operation is expensive; however, large declaration contexts are not
+ traversed in normal compilation, since such a traversal is unnecessary.
+ However, it is common for the code generator and semantic analysis to
+ traverse declaration contexts for structs, classes, unions, and
+ enumerations, although those contexts contain relatively few declarations in
+ the common case.
+
+Statements and Expressions
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Statements and expressions are stored in the AST file in both the :ref:`types
+<pchinternals-types>` and the :ref:`declarations <pchinternals-decls>` blocks,
+because every statement or expression will be associated with either a type or
+declaration. The actual statement and expression records are stored
+immediately following the declaration or type that owns the statement or
+expression. For example, the statement representing the body of a function
+will be stored directly following the declaration of the function.
+
+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
+expression ``3 - 4 + 5`` would be represented as follows:
+
++-----------------------+
+| ``IntegerLiteral(5)`` |
++-----------------------+
+| ``IntegerLiteral(4)`` |
++-----------------------+
+| ``IntegerLiteral(3)`` |
++-----------------------+
+| ``IntegerLiteral(-)`` |
++-----------------------+
+| ``IntegerLiteral(+)`` |
++-----------------------+
+| ``STOP`` |
++-----------------------+
+
+When reading this representation, Clang evaluates each expression record it
+encounters, builds the appropriate abstract syntax tree node, and then pushes
+that expression on to a stack. When a record contains *N* subexpressions ---
+``BinaryOperator`` has two of them --- those expressions are popped from the
+top of the stack. The special STOP code indicates that we have reached the end
+of a serialized expression or statement; other expression or statement records
+may follow, but they are part of a different expression.
+
+.. _pchinternals-ident-table:
+
+Identifier Table Block
+^^^^^^^^^^^^^^^^^^^^^^
+
+The identifier table block contains an on-disk hash table that maps each
+identifier mentioned within the AST file to the serialized representation of
+the identifier's information (e.g, the ``IdentifierInfo`` structure). The
+serialized representation contains:
+
+* The actual identifier string.
+* Flags that describe whether this identifier is the name of a built-in, a
+ poisoned identifier, an extension token, or a macro.
+* If the identifier names a macro, the offset of the macro definition within
+ the :ref:`pchinternals-preprocessor`.
+* If the identifier names one or more declarations visible from translation
+ unit scope, the :ref:`declaration IDs <pchinternals-decls>` of these
+ declarations.
+
+When an AST file is loaded, the AST file reader mechanism introduces itself
+into the identifier table as an external lookup source. Thus, when the user
+program refers to an identifier that has not yet been seen, Clang will perform
+a lookup into the identifier table. If an identifier is found, its contents
+(macro definitions, flags, top-level declarations, etc.) will be deserialized,
+at which point the corresponding ``IdentifierInfo`` structure will have the
+same contents it would have after parsing the headers in the AST file.
+
+Within the AST file, the identifiers used to name declarations are represented
+with an integral value. A separate table provides a mapping from this integral
+value (the identifier ID) to the location within the on-disk hash table where
+that identifier is stored. This mapping is used when deserializing the name of
+a declaration, the identifier of a token, or any other construct in the AST
+file that refers to a name.
+
+.. _pchinternals-method-pool:
+
+Method Pool Block
+^^^^^^^^^^^^^^^^^
+
+The method pool block is represented as an on-disk hash table that serves two
+purposes: it provides a mapping from the names of Objective-C selectors to the
+set of Objective-C instance and class methods that have that particular
+selector (which is required for semantic analysis in Objective-C) and also
+stores all of the selectors used by entities within the AST file. The design
+of the method pool is similar to that of the :ref:`identifier table
+<pchinternals-ident-table>`: the first time a particular selector is formed
+during the compilation of the program, Clang will search in the on-disk hash
+table of selectors; if found, Clang will read the Objective-C methods
+associated with that selector into the appropriate front-end data structure
+(``Sema::InstanceMethodPool`` and ``Sema::FactoryMethodPool`` for instance and
+class methods, respectively).
+
+As with identifiers, selectors are represented by numeric values within the AST
+file. A separate index maps these numeric selector values to the offset of the
+selector within the on-disk hash table, and will be used when de-serializing an
+Objective-C method declaration (or other Objective-C construct) that refers to
+the selector.
+
+AST Reader Integration Points
+-----------------------------
+
+The "lazy" deserialization behavior of AST files requires their integration
+into several completely different submodules of Clang. For example, lazily
+deserializing the declarations during name lookup requires that the name-lookup
+routines be able to query the AST file to find entities stored there.
+
+For each Clang data structure that requires direct interaction with the AST
+reader logic, there is an abstract class that provides the interface between
+the two modules. The ``ASTReader`` class, which handles the loading of an AST
+file, inherits from all of these abstract classes to provide lazy
+deserialization of Clang's data structures. ``ASTReader`` implements the
+following abstract classes:
+
+``ExternalSLocEntrySource``
+ This abstract interface is associated with the ``SourceManager`` class, and
+ is used whenever the :ref:`source manager <pchinternals-sourcemgr>` needs to
+ load the details of a file, buffer, or macro instantiation.
+
+``IdentifierInfoLookup``
+ This abstract interface is associated with the ``IdentifierTable`` class, and
+ is used whenever the program source refers to an identifier that has not yet
+ been seen. In this case, the AST reader searches for this identifier within
+ its :ref:`identifier table <pchinternals-ident-table>` to load any top-level
+ declarations or macros associated with that identifier.
+
+``ExternalASTSource``
+ This abstract interface is associated with the ``ASTContext`` class, and is
+ used whenever the abstract syntax tree nodes need to loaded from the AST
+ file. It provides the ability to de-serialize declarations and types
+ identified by their numeric values, read the bodies of functions when
+ required, and read the declarations stored within a declaration context
+ (either for iteration or for name lookup).
+
+``ExternalSemaSource``
+ This abstract interface is associated with the ``Sema`` class, and is used
+ whenever semantic analysis needs to read information from the :ref:`global
+ method pool <pchinternals-method-pool>`.
+
+.. _pchinternals-chained:
+
+Chained precompiled headers
+---------------------------
+
+Chained precompiled headers were initially intended to improve the performance
+of IDE-centric operations such as syntax highlighting and code completion while
+a particular source file is being edited by the user. To minimize the amount
+of reparsing required after a change to the file, a form of precompiled header
+--- called a precompiled *preamble* --- is automatically generated by parsing
+all of the headers in the source file, up to and including the last
+``#include``. When only the source file changes (and none of the headers it
+depends on), reparsing of that source file can use the precompiled preamble and
+start parsing after the ``#include``\ s, so parsing time is proportional to the
+size of the source file (rather than all of its includes). However, the
+compilation of that translation unit may already use a precompiled header: in
+this case, Clang will create the precompiled preamble as a chained precompiled
+header that refers to the original precompiled header. This drastically
+reduces the time needed to serialize the precompiled preamble for use in
+reparsing.
+
+Chained precompiled headers get their name because each precompiled header can
+depend on one other precompiled header, forming a chain of dependencies. A
+translation unit will then include the precompiled header that starts the chain
+(i.e., nothing depends on it). This linearity of dependencies is important for
+the semantic model of chained precompiled headers, because the most-recent
+precompiled header can provide information that overrides the information
+provided by the precompiled headers it depends on, just like a header file
+``B.h`` that includes another header ``A.h`` can modify the state produced by
+parsing ``A.h``, e.g., by ``#undef``'ing a macro defined in ``A.h``.
+
+There are several ways in which chained precompiled headers generalize the AST
+file model:
+
+Numbering of IDs
+ Many different kinds of entities --- identifiers, declarations, types, etc.
+ --- have ID numbers that start at 1 or some other predefined constant and
+ grow upward. Each precompiled header records the maximum ID number it has
+ assigned in each category. Then, when a new precompiled header is generated
+ that depends on (chains to) another precompiled header, it will start
+ counting at the next available ID number. This way, one can determine, given
+ an ID number, which AST file actually contains the entity.
+
+Name lookup
+ When writing a chained precompiled header, Clang attempts to write only
+ information that has changed from the precompiled header on which it is
+ based. This changes the lookup algorithm for the various tables, such as the
+ :ref:`identifier table <pchinternals-ident-table>`: the search starts at the
+ most-recent precompiled header. If no entry is found, lookup then proceeds
+ to the identifier table in the precompiled header it depends on, and so one.
+ Once a lookup succeeds, that result is considered definitive, overriding any
+ results from earlier precompiled headers.
+
+Update records
+ There are various ways in which a later precompiled header can modify the
+ entities described in an earlier precompiled header. For example, later
+ precompiled headers can add entries into the various name-lookup tables for
+ the translation unit or namespaces, or add new categories to an Objective-C
+ class. Each of these updates is captured in an "update record" that is
+ stored in the chained precompiled header file and will be loaded along with
+ the original entity.
+
+.. _pchinternals-modules:
+
+Modules
+-------
+
+Modules generalize the chained precompiled header model yet further, from a
+linear chain of precompiled headers to an arbitrary directed acyclic graph
+(DAG) of AST files. All of the same techniques used to make chained
+precompiled headers work --- ID number, name lookup, update records --- are
+shared with modules. However, the DAG nature of modules introduce a number of
+additional complications to the model:
+
+Numbering of IDs
+ The simple, linear numbering scheme used in chained precompiled headers falls
+ apart with the module DAG, because different modules may end up with
+ different numbering schemes for entities they imported from common shared
+ modules. To account for this, each module file provides information about
+ which modules it depends on and which ID numbers it assigned to the entities
+ in those modules, as well as which ID numbers it took for its own new
+ entities. The AST reader then maps these "local" ID numbers into a "global"
+ ID number space for the current translation unit, providing a 1-1 mapping
+ between entities (in whatever AST file they inhabit) and global ID numbers.
+ If that translation unit is then serialized into an AST file, this mapping
+ will be stored for use when the AST file is imported.
+
+Declaration merging
+ It is possible for a given entity (from the language's perspective) to be
+ declared multiple times in different places. For example, two different
+ headers can have the declaration of ``printf`` or could forward-declare
+ ``struct stat``. If each of those headers is included in a module, and some
+ third party imports both of those modules, there is a potentially serious
+ problem: name lookup for ``printf`` or ``struct stat`` will find both
+ declarations, but the AST nodes are unrelated. This would result in a
+ compilation error, due to an ambiguity in name lookup. Therefore, the AST
+ reader performs declaration merging according to the appropriate language
+ semantics, ensuring that the two disjoint declarations are merged into a
+ single redeclaration chain (with a common canonical declaration), so that it
+ is as if one of the headers had been included before the other.
+
+Name Visibility
+ Modules allow certain names that occur during module creation to be "hidden",
+ so that they are not part of the public interface of the module and are not
+ visible to its clients. The AST reader maintains a "visible" bit on various
+ AST nodes (declarations, macros, etc.) to indicate whether that particular
+ AST node is currently visible; the various name lookup mechanisms in Clang
+ inspect the visible bit to determine whether that entity, which is still in
+ the AST (because other, visible AST nodes may depend on it), can actually be
+ found by name lookup. When a new (sub)module is imported, it may make
+ existing, non-visible, already-deserialized AST nodes visible; it is the
+ responsibility of the AST reader to find and update these AST nodes when it
+ is notified of the import.
+
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/PTHInternals.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/PTHInternals.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/PTHInternals.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/PTHInternals.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,163 @@
+==========================
+Pretokenized Headers (PTH)
+==========================
+
+This document first describes the low-level interface for using PTH and
+then briefly elaborates on its design and implementation. If you are
+interested in the end-user view, please see the :ref:`User's Manual
+<usersmanual-precompiled-headers>`.
+
+Using Pretokenized Headers with ``clang`` (Low-level Interface)
+===============================================================
+
+The Clang compiler frontend, ``clang -cc1``, supports three command line
+options for generating and using PTH files.
+
+To generate PTH files using ``clang -cc1``, use the option ``-emit-pth``:
+
+.. code-block:: console
+
+ $ clang -cc1 test.h -emit-pth -o test.h.pth
+
+This option is transparently used by ``clang`` when generating PTH
+files. Similarly, PTH files can be used as prefix headers using the
+``-include-pth`` option:
+
+.. code-block:: console
+
+ $ clang -cc1 -include-pth test.h.pth test.c -o test.s
+
+Alternatively, Clang's PTH files can be used as a raw "token-cache" (or
+"content" cache) of the source included by the original header file.
+This means that the contents of the PTH file are searched as substitutes
+for *any* source files that are used by ``clang -cc1`` to process a
+source file. This is done by specifying the ``-token-cache`` option:
+
+.. code-block:: console
+
+ $ cat test.h
+ #include <stdio.h>
+ $ clang -cc1 -emit-pth test.h -o test.h.pth
+ $ cat test.c
+ #include "test.h"
+ $ clang -cc1 test.c -o test -token-cache test.h.pth
+
+In this example the contents of ``stdio.h`` (and the files it includes)
+will be retrieved from ``test.h.pth``, as the PTH file is being used in
+this case as a raw cache of the contents of ``test.h``. This is a
+low-level interface used to both implement the high-level PTH interface
+as well as to provide alternative means to use PTH-style caching.
+
+PTH Design and Implementation
+=============================
+
+Unlike GCC's precompiled headers, which cache the full ASTs and
+preprocessor state of a header file, Clang's pretokenized header files
+mainly cache the raw lexer *tokens* that are needed to segment the
+stream of characters in a source file into keywords, identifiers, and
+operators. Consequently, PTH serves to mainly directly speed up the
+lexing and preprocessing of a source file, while parsing and
+type-checking must be completely redone every time a PTH file is used.
+
+Basic Design Tradeoffs
+----------------------
+
+In the long term there are plans to provide an alternate PCH
+implementation for Clang that also caches the work for parsing and type
+checking the contents of header files. The current implementation of PCH
+in Clang as pretokenized header files was motivated by the following
+factors:
+
+**Language independence**
+ PTH files work with any language that
+ Clang's lexer can handle, including C, Objective-C, and (in the early
+ stages) C++. This means development on language features at the
+ parsing level or above (which is basically almost all interesting
+ pieces) does not require PTH to be modified.
+
+**Simple design**
+ Relatively speaking, PTH has a simple design and
+ implementation, making it easy to test. Further, because the
+ machinery for PTH resides at the lower-levels of the Clang library
+ stack it is fairly straightforward to profile and optimize.
+
+Further, compared to GCC's PCH implementation (which is the dominate
+precompiled header file implementation that Clang can be directly
+compared against) the PTH design in Clang yields several attractive
+features:
+
+**Architecture independence**
+ In contrast to GCC's PCH files (and
+ those of several other compilers), Clang's PTH files are architecture
+ independent, requiring only a single PTH file when building a
+ program for multiple architectures.
+
+ For example, on Mac OS X one may wish to compile a "universal binary"
+ that runs on PowerPC, 32-bit Intel (i386), and 64-bit Intel
+ architectures. In contrast, GCC requires a PCH file for each
+ architecture, as the definitions of types in the AST are
+ architecture-specific. Since a Clang PTH file essentially represents
+ a lexical cache of header files, a single PTH file can be safely used
+ when compiling for multiple architectures. This can also reduce
+ compile times because only a single PTH file needs to be generated
+ during a build instead of several.
+
+**Reduced memory pressure**
+ Similar to GCC, Clang reads PTH files
+ via the use of memory mapping (i.e., ``mmap``). Clang, however,
+ memory maps PTH files as read-only, meaning that multiple invocations
+ of ``clang -cc1`` can share the same pages in memory from a
+ memory-mapped PTH file. In comparison, GCC also memory maps its PCH
+ files but also modifies those pages in memory, incurring the
+ copy-on-write costs. The read-only nature of PTH can greatly reduce
+ memory pressure for builds involving multiple cores, thus improving
+ overall scalability.
+
+**Fast generation**
+ PTH files can be generated in a small fraction
+ of the time needed to generate GCC's PCH files. Since PTH/PCH
+ generation is a serial operation that typically blocks progress
+ during a build, faster generation time leads to improved processor
+ utilization with parallel builds on multicore machines.
+
+Despite these strengths, PTH's simple design suffers some algorithmic
+handicaps compared to other PCH strategies such as those used by GCC.
+While PTH can greatly speed up the processing time of a header file, the
+amount of work required to process a header file is still roughly linear
+in the size of the header file. In contrast, the amount of work done by
+GCC to process a precompiled header is (theoretically) constant (the
+ASTs for the header are literally memory mapped into the compiler). This
+means that only the pieces of the header file that are referenced by the
+source file including the header are the only ones the compiler needs to
+process during actual compilation. While GCC's particular implementation
+of PCH mitigates some of these algorithmic strengths via the use of
+copy-on-write pages, the approach itself can fundamentally dominate at
+an algorithmic level, especially when one considers header files of
+arbitrary size.
+
+There is also a PCH implementation for Clang based on the lazy
+deserialization of ASTs. This approach theoretically has the same
+constant-time algorithmic advantages just mentioned but also retains some
+of the strengths of PTH such as reduced memory pressure (ideal for
+multi-core builds).
+
+Internal PTH Optimizations
+--------------------------
+
+While the main optimization employed by PTH is to reduce lexing time of
+header files by caching pre-lexed tokens, PTH also employs several other
+optimizations to speed up the processing of header files:
+
+- ``stat`` caching: PTH files cache information obtained via calls to
+ ``stat`` that ``clang -cc1`` uses to resolve which files are included
+ by ``#include`` directives. This greatly reduces the overhead
+ involved in context-switching to the kernel to resolve included
+ files.
+
+- Fast skipping of ``#ifdef`` ... ``#endif`` chains: PTH files
+ record the basic structure of nested preprocessor blocks. When the
+ condition of the preprocessor block is false, all of its tokens are
+ immediately skipped instead of requiring them to be handled by
+ Clang's preprocessor.
+
+
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/RAVFrontendAction.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/RAVFrontendAction.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/RAVFrontendAction.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/RAVFrontendAction.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,219 @@
+==========================================================
+How to write RecursiveASTVisitor based ASTFrontendActions.
+==========================================================
+
+Introduction
+============
+
+In this tutorial you will learn how to create a FrontendAction that uses
+a RecursiveASTVisitor to find CXXRecordDecl AST nodes with a specified
+name.
+
+Creating a FrontendAction
+=========================
+
+When writing a clang based tool like a Clang Plugin or a standalone tool
+based on LibTooling, the common entry point is the FrontendAction.
+FrontendAction is an interface that allows execution of user specific
+actions as part of the compilation. To run tools over the AST clang
+provides the convenience interface ASTFrontendAction, which takes care
+of executing the action. The only part left is to implement the
+CreateASTConsumer method that returns an ASTConsumer per translation
+unit.
+
+::
+
+ class FindNamedClassAction : public clang::ASTFrontendAction {
+ public:
+ virtual std::unique_ptr<clang::ASTConsumer> CreateASTConsumer(
+ clang::CompilerInstance &Compiler, llvm::StringRef InFile) {
+ return std::unique_ptr<clang::ASTConsumer>(
+ new FindNamedClassConsumer);
+ }
+ };
+
+Creating an ASTConsumer
+=======================
+
+ASTConsumer is an interface used to write generic actions on an AST,
+regardless of how the AST was produced. ASTConsumer provides many
+different entry points, but for our use case the only one needed is
+HandleTranslationUnit, which is called with the ASTContext for the
+translation unit.
+
+::
+
+ class FindNamedClassConsumer : public clang::ASTConsumer {
+ public:
+ virtual void HandleTranslationUnit(clang::ASTContext &Context) {
+ // Traversing the translation unit decl via a RecursiveASTVisitor
+ // will visit all nodes in the AST.
+ Visitor.TraverseDecl(Context.getTranslationUnitDecl());
+ }
+ private:
+ // A RecursiveASTVisitor implementation.
+ FindNamedClassVisitor Visitor;
+ };
+
+Using the RecursiveASTVisitor
+=============================
+
+Now that everything is hooked up, the next step is to implement a
+RecursiveASTVisitor to extract the relevant information from the AST.
+
+The RecursiveASTVisitor provides hooks of the form bool
+VisitNodeType(NodeType \*) for most AST nodes; the exception are TypeLoc
+nodes, which are passed by-value. We only need to implement the methods
+for the relevant node types.
+
+Let's start by writing a RecursiveASTVisitor that visits all
+CXXRecordDecl's.
+
+::
+
+ class FindNamedClassVisitor
+ : public RecursiveASTVisitor<FindNamedClassVisitor> {
+ public:
+ bool VisitCXXRecordDecl(CXXRecordDecl *Declaration) {
+ // For debugging, dumping the AST nodes will show which nodes are already
+ // being visited.
+ Declaration->dump();
+
+ // The return value indicates whether we want the visitation to proceed.
+ // Return false to stop the traversal of the AST.
+ return true;
+ }
+ };
+
+In the methods of our RecursiveASTVisitor we can now use the full power
+of the Clang AST to drill through to the parts that are interesting for
+us. For example, to find all class declaration with a certain name, we
+can check for a specific qualified name:
+
+::
+
+ bool VisitCXXRecordDecl(CXXRecordDecl *Declaration) {
+ if (Declaration->getQualifiedNameAsString() == "n::m::C")
+ Declaration->dump();
+ return true;
+ }
+
+Accessing the SourceManager and ASTContext
+==========================================
+
+Some of the information about the AST, like source locations and global
+identifier information, are not stored in the AST nodes themselves, but
+in the ASTContext and its associated source manager. To retrieve them we
+need to hand the ASTContext into our RecursiveASTVisitor implementation.
+
+The ASTContext is available from the CompilerInstance during the call to
+CreateASTConsumer. We can thus extract it there and hand it into our
+freshly created FindNamedClassConsumer:
+
+::
+
+ virtual std::unique_ptr<clang::ASTConsumer> CreateASTConsumer(
+ clang::CompilerInstance &Compiler, llvm::StringRef InFile) {
+ return std::unique_ptr<clang::ASTConsumer>(
+ new FindNamedClassConsumer(&Compiler.getASTContext()));
+ }
+
+Now that the ASTContext is available in the RecursiveASTVisitor, we can
+do more interesting things with AST nodes, like looking up their source
+locations:
+
+::
+
+ bool VisitCXXRecordDecl(CXXRecordDecl *Declaration) {
+ if (Declaration->getQualifiedNameAsString() == "n::m::C") {
+ // getFullLoc uses the ASTContext's SourceManager to resolve the source
+ // location and break it up into its line and column parts.
+ FullSourceLoc FullLocation = Context->getFullLoc(Declaration->getLocStart());
+ if (FullLocation.isValid())
+ llvm::outs() << "Found declaration at "
+ << FullLocation.getSpellingLineNumber() << ":"
+ << FullLocation.getSpellingColumnNumber() << "\n";
+ }
+ return true;
+ }
+
+Putting it all together
+=======================
+
+Now we can combine all of the above into a small example program:
+
+::
+
+ #include "clang/AST/ASTConsumer.h"
+ #include "clang/AST/RecursiveASTVisitor.h"
+ #include "clang/Frontend/CompilerInstance.h"
+ #include "clang/Frontend/FrontendAction.h"
+ #include "clang/Tooling/Tooling.h"
+
+ using namespace clang;
+
+ class FindNamedClassVisitor
+ : public RecursiveASTVisitor<FindNamedClassVisitor> {
+ public:
+ explicit FindNamedClassVisitor(ASTContext *Context)
+ : Context(Context) {}
+
+ bool VisitCXXRecordDecl(CXXRecordDecl *Declaration) {
+ if (Declaration->getQualifiedNameAsString() == "n::m::C") {
+ FullSourceLoc FullLocation = Context->getFullLoc(Declaration->getLocStart());
+ if (FullLocation.isValid())
+ llvm::outs() << "Found declaration at "
+ << FullLocation.getSpellingLineNumber() << ":"
+ << FullLocation.getSpellingColumnNumber() << "\n";
+ }
+ return true;
+ }
+
+ private:
+ ASTContext *Context;
+ };
+
+ class FindNamedClassConsumer : public clang::ASTConsumer {
+ public:
+ explicit FindNamedClassConsumer(ASTContext *Context)
+ : Visitor(Context) {}
+
+ virtual void HandleTranslationUnit(clang::ASTContext &Context) {
+ Visitor.TraverseDecl(Context.getTranslationUnitDecl());
+ }
+ private:
+ FindNamedClassVisitor Visitor;
+ };
+
+ class FindNamedClassAction : public clang::ASTFrontendAction {
+ public:
+ virtual std::unique_ptr<clang::ASTConsumer> CreateASTConsumer(
+ clang::CompilerInstance &Compiler, llvm::StringRef InFile) {
+ return std::unique_ptr<clang::ASTConsumer>(
+ new FindNamedClassConsumer(&Compiler.getASTContext()));
+ }
+ };
+
+ int main(int argc, char **argv) {
+ if (argc > 1) {
+ clang::tooling::runToolOnCode(new FindNamedClassAction, argv[1]);
+ }
+ }
+
+We store this into a file called FindClassDecls.cpp and create the
+following CMakeLists.txt to link it:
+
+::
+
+ add_clang_executable(find-class-decls FindClassDecls.cpp)
+
+ target_link_libraries(find-class-decls clangTooling)
+
+When running this tool over a small code snippet it will output all
+declarations of a class n::m::C it found:
+
+::
+
+ $ ./bin/find-class-decls "namespace n { namespace m { class C {}; } }"
+ Found declaration at 1:29
+
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/ReleaseNotes.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/ReleaseNotes.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/ReleaseNotes.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/ReleaseNotes.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,372 @@
+=========================
+Clang 5.0.0 Release Notes
+=========================
+
+.. contents::
+ :local:
+ :depth: 2
+
+Written by the `LLVM Team <http://llvm.org/>`_
+
+Introduction
+============
+
+This document contains the release notes for the Clang C/C++/Objective-C
+frontend, part of the LLVM Compiler Infrastructure, release 5.0.0. Here we
+describe the status of Clang in some detail, including major
+improvements from the previous release and new feature work. For the
+general LLVM release notes, see `the LLVM
+documentation <http://llvm.org/docs/ReleaseNotes.html>`_. All LLVM
+releases may be downloaded from the `LLVM releases web
+site <http://llvm.org/releases/>`_.
+
+For more information about Clang or LLVM, including information about the
+latest release, please see the `Clang Web Site <http://clang.llvm.org>`_ or the
+`LLVM Web Site <http://llvm.org>`_.
+
+What's New in Clang 5.0.0?
+==========================
+
+Some of the major new features and improvements to Clang are listed
+here. Generic improvements to Clang as a whole or to its underlying
+infrastructure are described first, followed by language-specific
+sections with improvements to Clang's support for those languages.
+
+Major New Features
+------------------
+
+C++ coroutines
+^^^^^^^^^^^^^^
+`C++ coroutines TS
+<http://open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4680.pdf>`_
+implementation has landed. Use ``-fcoroutines-ts -stdlib=libc++`` to enable
+coroutine support. Here is `an example
+<https://wandbox.org/permlink/Dth1IO5q8Oe31ew2>`_ to get you started.
+
+
+Improvements to Clang's diagnostics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+- ``-Wcast-qual`` was implemented for C++. C-style casts are now properly
+ diagnosed.
+
+- ``-Wunused-lambda-capture`` warns when a variable explicitly captured
+ by a lambda is not used in the body of the lambda.
+
+- ``-Wstrict-prototypes`` is a new warning that warns about non-prototype
+ function and block declarations and types in C and Objective-C.
+
+- ``-Wunguarded-availability`` is a new warning that warns about uses of new
+ APIs that were introduced in a system whose version is newer than the
+ deployment target version. A new Objective-C expression ``@available`` has
+ been introduced to perform system version checking at runtime. This warning
+ is off by default to prevent unexpected warnings in existing projects.
+ However, its less strict sibling ``-Wunguarded-availability-new`` is on by
+ default. It warns about unguarded uses of APIs only when they were introduced
+ in or after macOS 10.13, iOS 11, tvOS 11 or watchOS 4.
+
+- The ``-Wdocumentation`` warning now allows the use of ``\param`` and
+ ``\returns`` documentation directives in the documentation comments for
+ declarations with a function or a block pointer type.
+
+- The compiler no longer warns about unreachable ``__builtin_unreachable``
+ statements.
+
+New Compiler Flags
+------------------
+
+- ``--autocomplete`` was implemented to obtain a list of flags and its arguments.
+ This is used for shell autocompletion.
+
+Deprecated Compiler Flags
+-------------------------
+
+The following options are deprecated and ignored. They will be removed in
+future versions of Clang.
+
+- ``-fslp-vectorize-aggressive`` used to enable the BB vectorizing pass. They have been superseeded
+ by the normal SLP vectorizer.
+- ``-fno-slp-vectorize-aggressive`` used to be the default behavior of clang.
+
+New Pragmas in Clang
+-----------------------
+
+- Clang now supports the ``clang attribute`` pragma that allows users to apply
+ an attribute to multiple declarations.
+
+- ``pragma pack`` directives that are included in a precompiled header are now
+ applied correctly to the declarations in the compilation unit that includes
+ that precompiled header.
+
+Attribute Changes in Clang
+--------------------------
+
+- The ``overloadable`` attribute now allows at most one function with a given
+ name to lack the ``overloadable`` attribute. This unmarked function will not
+ have its name mangled.
+- The ``ms_abi`` attribute and the ``__builtin_ms_va_list`` types and builtins
+ are now supported on AArch64.
+
+C Language Changes in Clang
+---------------------------
+
+- Added near complete support for implicit scalar to vector conversion, a GNU
+ C/C++ language extension. With this extension, the following code is
+ considered valid:
+
+.. code-block:: c
+
+ typedef unsigned v4i32 __attribute__((vector_size(16)));
+
+ v4i32 foo(v4i32 a) {
+ // Here 5 is implicitly casted to an unsigned value and replicated into a
+ // vector with as many elements as 'a'.
+ return a + 5;
+ }
+
+The implicit conversion of a scalar value to a vector value--in the context of
+a vector expression--occurs when:
+
+- The type of the vector is that of a ``__attribute__((vector_size(size)))``
+ vector, not an OpenCL ``__attribute__((ext_vector_type(size)))`` vector type.
+
+- The scalar value can be casted to that of the vector element's type without
+ the loss of precision based on the type of the scalar and the type of the
+ vector's elements.
+
+- For compile time constant values, the above rule is weakened to consider the
+ value of the scalar constant rather than the constant's type. However,
+ for compatibility with GCC, floating point constants with precise integral
+ representations are not implicitly converted to integer values.
+
+Currently the basic integer and floating point types with the following
+operators are supported: ``+``, ``/``, ``-``, ``*``, ``%``, ``>``, ``<``,
+``>=``, ``<=``, ``==``, ``!=``, ``&``, ``|``, ``^`` and the corresponding
+assignment operators where applicable.
+
+
+C++ Language Changes in Clang
+-----------------------------
+
+- We expect this to be the last Clang release that defaults to ``-std=gnu++98``
+ when using the GCC-compatible ``clang++`` driver. From Clang 6 onwards we
+ expect to use ``-std=gnu++14`` or a later standard by default, to match the
+ behavior of recent GCC releases. Users are encouraged to change their build
+ files to explicitly specify their desired C++ standard.
+
+- Support for the C++17 standard has been completed. This mode can be enabled
+ using ``-std=c++17`` (the old flag ``-std=c++1z`` is still supported for
+ compatibility).
+
+- When targeting a platform that uses the Itanium C++ ABI, Clang implements a
+ `recent change to the ABI`__ that passes objects of class type indirectly if they
+ have a non-trivial move constructor. Previous versions of Clang only
+ considered the copy constructor, resulting in an ABI change in rare cases,
+ but GCC has already implemented this change for several releases.
+ This affects all targets other than Windows and PS4. You can opt out of this
+ ABI change with ``-fclang-abi-compat=4.0``.
+
+- As mentioned in `C Language Changes in Clang`_, Clang's support for
+ implicit scalar to vector conversions also applies to C++. Additionally
+ the following operators are also supported: ``&&`` and ``||``.
+
+.. __: https://github.com/itanium-cxx-abi/cxx-abi/commit/7099637aba11fed6bdad7ee65bf4fd3f97fbf076
+
+Objective-C Language Changes in Clang
+-------------------------------------
+
+- Clang now guarantees that a ``readwrite`` property is synthesized when an
+ ambiguous property (i.e. a property that's declared in multiple protocols)
+ is synthesized. The ``-Wprotocol-property-synthesis-ambiguity`` warning that
+ warns about incompatible property types is now promoted to an error when
+ there's an ambiguity between ``readwrite`` and ``readonly`` properties.
+
+- Clang now prohibits synthesis of ambiguous properties with incompatible
+ explicit property attributes. The following property attributes are
+ checked for differences: ``copy``, ``retain``/``strong``, ``atomic``,
+ ``getter`` and ``setter``.
+
+OpenCL C Language Changes in Clang
+----------------------------------
+
+Various bug fixes and improvements:
+
+- Extended OpenCL-related Clang tests.
+
+- Improved diagnostics across several areas: scoped address space
+ qualified variables, function pointers, atomics, type rank for overloading,
+ block captures, ``reserve_id_t``.
+
+- Several address space related fixes for constant address space function scope variables,
+ IR generation, mangling of ``generic`` and alloca (post-fix from general Clang
+ refactoring of address spaces).
+
+- Several improvements in extensions: fixed OpenCL version for ``cl_khr_mipmap_image``,
+ added missing ``cl_khr_3d_image_writes``.
+
+- Improvements in ``enqueue_kernel``, especially the implementation of ``ndrange_t`` and blocks.
+
+- OpenCL type related fixes: global samplers, the ``pipe_t`` size, internal type redefinition,
+ and type compatibility checking in ternary and other operations.
+
+- The OpenCL header has been extended with missing extension guards, and direct mapping of ``as_type``
+ to ``__builtin_astype``.
+
+- Fixed ``kernel_arg_type_qual`` and OpenCL/SPIR version in metadata.
+
+- Added proper use of the kernel calling convention to various targets.
+
+The following new functionalities have been added:
+
+- Added documentation on OpenCL to Clang user manual.
+
+- Extended Clang builtins with required ``cl_khr_subgroups`` support.
+
+- Add ``intel_reqd_sub_group_size`` attribute support.
+
+- Added OpenCL types to ``CIndex``.
+
+
+clang-format
+------------
+
+* Option **BreakBeforeInheritanceComma** added to break before ``:`` and ``,`` in case of
+ multiple inheritance in a class declaration. Enabled by default in the Mozilla coding style.
+
+ +---------------------+----------------------------------------+
+ | true | false |
+ +=====================+========================================+
+ | .. code-block:: c++ | .. code-block:: c++ |
+ | | |
+ | class MyClass | class MyClass : public X, public Y { |
+ | : public X | }; |
+ | , public Y { | |
+ | }; | |
+ +---------------------+----------------------------------------+
+
+* Align block comment decorations.
+
+ +----------------------+---------------------+
+ | Before | After |
+ +======================+=====================+
+ | .. code-block:: c++ | .. code-block:: c++ |
+ | | |
+ | /* line 1 | /* line 1 |
+ | * line 2 | * line 2 |
+ | */ | */ |
+ +----------------------+---------------------+
+
+* The :doc:`ClangFormatStyleOptions` documentation provides detailed examples for most options.
+
+* Namespace end comments are now added or updated automatically.
+
+ +---------------------+---------------------+
+ | Before | After |
+ +=====================+=====================+
+ | .. code-block:: c++ | .. code-block:: c++ |
+ | | |
+ | namespace A { | namespace A { |
+ | int i; | int i; |
+ | int j; | int j; |
+ | } | } // namespace A |
+ +---------------------+---------------------+
+
+* Comment reflow support added. Overly long comment lines will now be reflown with the rest of
+ the paragraph instead of just broken. Option **ReflowComments** added and enabled by default.
+
+libclang
+--------
+
+- Libclang now provides code-completion results for more C++ constructs
+ and keywords. The following keywords/identifiers are now included in the
+ code-completion results: ``static_assert``, ``alignas``, ``constexpr``,
+ ``final``, ``noexcept``, ``override`` and ``thread_local``.
+
+- Libclang now provides code-completion results for members from dependent
+ classes. For example:
+
+ .. code-block:: c++
+
+ template<typename T>
+ void appendValue(std::vector<T> &dest, const T &value) {
+ dest. // Relevant completion results are now shown after '.'
+ }
+
+ Note that code-completion results are still not provided when the member
+ expression includes a dependent base expression. For example:
+
+ .. code-block:: c++
+
+ template<typename T>
+ void appendValue(std::vector<std::vector<T>> &dest, const T &value) {
+ dest.at(0). // Libclang fails to provide completion results after '.'
+ }
+
+Static Analyzer
+---------------
+
+- The static analyzer now supports using the
+ `z3 theorem prover <https://github.com/z3prover/z3>`_ from Microsoft Research
+ as an external constraint solver. This allows reasoning over more complex
+ queries, but performance is ~15x slower than the default range-based
+ constraint solver. To enable the z3 solver backend, clang must be built with
+ the ``CLANG_ANALYZER_BUILD_Z3=ON`` option, and the
+ ``-Xanalyzer -analyzer-constraints=z3`` arguments passed at runtime.
+
+Undefined Behavior Sanitizer (UBSan)
+------------------------------------
+
+- The Undefined Behavior Sanitizer has a new check for pointer overflow. This
+ check is on by default. The flag to control this functionality is
+ ``-fsanitize=pointer-overflow``.
+
+ Pointer overflow is an indicator of undefined behavior: when a pointer
+ indexing expression wraps around the address space, or produces other
+ unexpected results, its result may not point to a valid object.
+
+- UBSan has several new checks which detect violations of nullability
+ annotations. These checks are off by default. The flag to control this group
+ of checks is ``-fsanitize=nullability``. The checks can be individially enabled
+ by ``-fsanitize=nullability-arg`` (which checks calls),
+ ``-fsanitize=nullability-assign`` (which checks assignments), and
+ ``-fsanitize=nullability-return`` (which checks return statements).
+
+- UBSan can now detect invalid loads from bitfields and from ObjC BOOLs.
+
+- UBSan can now avoid emitting unnecessary type checks in C++ class methods and
+ in several other cases where the result is known at compile-time. UBSan can
+ also avoid emitting unnecessary overflow checks in arithmetic expressions
+ with promoted integer operands.
+
+
+Python Binding Changes
+----------------------
+
+Python bindings now support both Python 2 and Python 3.
+
+The following methods have been added:
+
+- ``is_scoped_enum`` has been added to ``Cursor``.
+
+- ``exception_specification_kind`` has been added to ``Cursor``.
+
+- ``get_address_space`` has been added to ``Type``.
+
+- ``get_typedef_name`` has been added to ``Type``.
+
+- ``get_exception_specification_kind`` has been added to ``Type``.
+
+
+Additional Information
+======================
+
+A wide variety of additional information is available on the `Clang web
+page <http://clang.llvm.org/>`_. The web page contains versions of the
+API documentation which are up-to-date with the Subversion version of
+the source code. You can access versions of these documents specific to
+this release by going into the "``clang/docs/``" directory in the Clang
+tree.
+
+If you have any questions or comments about Clang, please feel free to
+contact us via the `mailing
+list <http://lists.llvm.org/mailman/listinfo/cfe-dev>`_.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/SafeStack.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/SafeStack.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/SafeStack.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/SafeStack.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,198 @@
+=========
+SafeStack
+=========
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+SafeStack is an instrumentation pass that protects programs against attacks
+based on stack buffer overflows, without introducing any measurable performance
+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/>`_.
+
+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
+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
+stack increases the locality of frequently accessed values on the stack, such
+as register spills, return addresses, and small local variables.
+
+Compatibility
+-------------
+
+Most programs, static libraries, or individual files can be compiled
+with SafeStack as is. SafeStack requires basic runtime support, which, on most
+platforms, is implemented as a compiler-rt library that is automatically linked
+in when the program is compiled with SafeStack.
+
+Linking a DSO with SafeStack is not currently supported.
+
+Known compatibility limitations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Certain code that relies on low-level stack manipulations requires adaption to
+work with SafeStack. One example is mark-and-sweep garbage collection
+implementations for C/C++ (e.g., Oilpan in chromium/blink), which must be
+changed to look for the live pointers on both safe and unsafe stacks.
+
+SafeStack supports linking statically modules that are compiled with and
+without SafeStack. An executable compiled with SafeStack can load dynamic
+libraries that are not compiled with SafeStack. At the moment, compiling
+dynamic libraries with SafeStack is not supported.
+
+Signal handlers that use ``sigaltstack()`` must not use the unsafe stack (see
+``__attribute__((no_sanitize("safe-stack")))`` below).
+
+Programs that use APIs from ``ucontext.h`` are not supported yet.
+
+Security
+--------
+
+SafeStack protects return addresses, spilled registers and local variables that
+are always accessed in a safe way by separating them in a dedicated safe stack
+region. The safe stack is automatically protected against stack-based buffer
+overflows, since it is disjoint from the unsafe stack in memory, and it itself
+is always accessed in a safe way. In the current implementation, the safe stack
+is protected against arbitrary memory write vulnerabilities though
+randomization and information hiding: the safe stack is allocated at a random
+address and the instrumentation ensures that no pointers to the safe stack are
+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
+mechanism that enforces correct calling conventions at indirect call sites,
+such as `IFCC <http://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,
+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
+the SafeStack instrumentation in final binaries.
+
+Usage
+=====
+
+To enable SafeStack, just pass ``-fsanitize=safe-stack`` flag to both compile
+and link command lines.
+
+Supported Platforms
+-------------------
+
+SafeStack was tested on Linux, FreeBSD and MacOSX.
+
+Low-level API
+-------------
+
+``__has_feature(safe_stack)``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In some rare cases one may need to execute different code depending on
+whether SafeStack is enabled. The macro ``__has_feature(safe_stack)`` can
+be used for this purpose.
+
+.. code-block:: c
+
+ #if __has_feature(safe_stack)
+ // code that builds only under SafeStack
+ #endif
+
+``__attribute__((no_sanitize("safe-stack")))``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Use ``__attribute__((no_sanitize("safe-stack")))`` on a function declaration
+to specify that the safe stack instrumentation should not be applied to that
+function, even if enabled globally (see ``-fsanitize=safe-stack`` flag). This
+attribute may be required for functions that make assumptions about the
+exact layout of their stack frames.
+
+All local variables in functions with this attribute will be stored on the safe
+stack. The safe stack remains unprotected against memory errors when accessing
+these variables, so extra care must be taken to manually ensure that all such
+accesses are safe. Furthermore, the addresses of such local variables should
+never be stored on the heap, as it would leak the location of the SafeStack.
+
+``__builtin___get_unsafe_stack_ptr()``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This builtin function returns current unsafe stack pointer of the current
+thread.
+
+``__builtin___get_unsafe_stack_start()``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This builtin function returns a pointer to the start of the unsafe stack of the
+current thread.
+
+Design
+======
+
+Please refer to the `Code-Pointer Integrity <http://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
+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>`__.
+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
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerCoverage.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerCoverage.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerCoverage.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerCoverage.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,335 @@
+=================
+SanitizerCoverage
+=================
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+LLVM has a simple code coverage instrumentation built in (SanitizerCoverage).
+It inserts calls to user-defined functions on function-, basic-block-, and edge- levels.
+Default implementations of those callbacks are provided and implement
+simple coverage reporting and visualization,
+however if you need *just* coverage visualization you may want to use
+:doc:`SourceBasedCodeCoverage <SourceBasedCodeCoverage>` instead.
+
+Tracing PCs with guards
+=======================
+
+With ``-fsanitize-coverage=trace-pc-guard`` the compiler will insert the following code
+on every edge:
+
+.. code-block:: none
+
+ __sanitizer_cov_trace_pc_guard(&guard_variable)
+
+Every edge will have its own `guard_variable` (uint32_t).
+
+The compler will also insert calls to a module constructor:
+
+.. code-block:: c++
+
+ // The guards are [start, stop).
+ // This function will be called at least once per DSO and may be called
+ // more than once with the same values of start/stop.
+ __sanitizer_cov_trace_pc_guard_init(uint32_t *start, uint32_t *stop);
+
+With an additional ``...=trace-pc,indirect-calls`` flag
+``__sanitizer_cov_trace_pc_indirect(void *callee)`` will be inserted on every indirect call.
+
+The functions `__sanitizer_cov_trace_pc_*` should be defined by the user.
+
+Example:
+
+.. code-block:: c++
+
+ // trace-pc-guard-cb.cc
+ #include <stdint.h>
+ #include <stdio.h>
+ #include <sanitizer/coverage_interface.h>
+
+ // This callback is inserted by the compiler as a module constructor
+ // into every DSO. 'start' and 'stop' correspond to the
+ // beginning and end of the section with the guards for the entire
+ // binary (executable or DSO). The callback will be called at least
+ // once per DSO and may be called multiple times with the same parameters.
+ extern "C" void __sanitizer_cov_trace_pc_guard_init(uint32_t *start,
+ uint32_t *stop) {
+ static uint64_t N; // Counter for the guards.
+ if (start == stop || *start) return; // Initialize only once.
+ printf("INIT: %p %p\n", start, stop);
+ for (uint32_t *x = start; x < stop; x++)
+ *x = ++N; // Guards should start from 1.
+ }
+
+ // This callback is inserted by the compiler on every edge in the
+ // control flow (some optimizations apply).
+ // Typically, the compiler will emit the code like this:
+ // if(*guard)
+ // __sanitizer_cov_trace_pc_guard(guard);
+ // But for large functions it will emit a simple call:
+ // __sanitizer_cov_trace_pc_guard(guard);
+ extern "C" void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
+ if (!*guard) return; // Duplicate the guard check.
+ // If you set *guard to 0 this code will not be called again for this edge.
+ // Now you can get the PC and do whatever you want:
+ // store it somewhere or symbolize it and print right away.
+ // The values of `*guard` are as you set them in
+ // __sanitizer_cov_trace_pc_guard_init and so you can make them consecutive
+ // and use them to dereference an array or a bit vector.
+ void *PC = __builtin_return_address(0);
+ char PcDescr[1024];
+ // This function is a part of the sanitizer run-time.
+ // To use it, link with AddressSanitizer or other sanitizer.
+ __sanitizer_symbolize_pc(PC, "%p %F %L", PcDescr, sizeof(PcDescr));
+ printf("guard: %p %x PC %s\n", guard, *guard, PcDescr);
+ }
+
+.. code-block:: c++
+
+ // trace-pc-guard-example.cc
+ void foo() { }
+ int main(int argc, char **argv) {
+ if (argc > 1) foo();
+ }
+
+.. code-block:: console
+
+ clang++ -g -fsanitize-coverage=trace-pc-guard trace-pc-guard-example.cc -c
+ clang++ trace-pc-guard-cb.cc trace-pc-guard-example.o -fsanitize=address
+ ASAN_OPTIONS=strip_path_prefix=`pwd`/ ./a.out
+
+.. code-block:: console
+
+ INIT: 0x71bcd0 0x71bce0
+ guard: 0x71bcd4 2 PC 0x4ecd5b in main trace-pc-guard-example.cc:2
+ guard: 0x71bcd8 3 PC 0x4ecd9e in main trace-pc-guard-example.cc:3:7
+
+.. code-block:: console
+
+ ASAN_OPTIONS=strip_path_prefix=`pwd`/ ./a.out with-foo
+
+
+.. code-block:: console
+
+ INIT: 0x71bcd0 0x71bce0
+ guard: 0x71bcd4 2 PC 0x4ecd5b in main trace-pc-guard-example.cc:3
+ guard: 0x71bcdc 4 PC 0x4ecdc7 in main trace-pc-guard-example.cc:4:17
+ guard: 0x71bcd0 1 PC 0x4ecd20 in foo() trace-pc-guard-example.cc:2:14
+
+Tracing PCs
+===========
+
+With ``-fsanitize-coverage=trace-pc`` the compiler will insert
+``__sanitizer_cov_trace_pc()`` on every edge.
+With an additional ``...=trace-pc,indirect-calls`` flag
+``__sanitizer_cov_trace_pc_indirect(void *callee)`` will be inserted on every indirect call.
+These callbacks are not implemented in the Sanitizer run-time and should be defined
+by the user.
+This mechanism is used for fuzzing the Linux kernel
+(https://github.com/google/syzkaller).
+
+
+Instrumentation points
+======================
+Sanitizer Coverage offers different levels of instrumentation.
+
+* ``edge`` (default): edges are instrumented (see below).
+* ``bb``: basic blocks are instrumented.
+* ``func``: only the entry block of every function will be instrumented.
+
+Use these flags together with ``trace-pc-guard`` or ``trace-pc``,
+like this: ``-fsanitize-coverage=func,trace-pc-guard``.
+
+When ``edge`` or ``bb`` is used, some of the edges/blocks may still be left
+uninstrumented (pruned) if such instrumentation is considered redundant.
+Use ``no-prune`` (e.g. ``-fsanitize-coverage=bb,no-prune,trace-pc-guard``)
+to disable pruning. This could be useful for better coverage visualization.
+
+
+Edge coverage
+-------------
+
+Consider this code:
+
+.. code-block:: c++
+
+ void foo(int *a) {
+ if (a)
+ *a = 0;
+ }
+
+It contains 3 basic blocks, let's name them A, B, C:
+
+.. code-block:: none
+
+ A
+ |\
+ | \
+ | 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:
+
+.. code-block:: none
+
+ A
+ |\
+ | \
+ D B
+ | /
+ |/
+ C
+
+Tracing data flow
+=================
+
+Support for data-flow-guided fuzzing.
+With ``-fsanitize-coverage=trace-cmp`` the compiler will insert extra instrumentation
+around comparison instructions and switch statements.
+Similarly, with ``-fsanitize-coverage=trace-div`` the compiler will instrument
+integer division instructions (to capture the right argument of division)
+and with ``-fsanitize-coverage=trace-gep`` --
+the `LLVM GEP instructions <http://llvm.org/docs/GetElementPtr.html>`_
+(to capture array indices).
+
+.. code-block:: c++
+
+ // Called before a comparison instruction.
+ // Arg1 and Arg2 are arguments of the comparison.
+ void __sanitizer_cov_trace_cmp1(uint8_t Arg1, uint8_t Arg2);
+ void __sanitizer_cov_trace_cmp2(uint16_t Arg1, uint16_t Arg2);
+ void __sanitizer_cov_trace_cmp4(uint32_t Arg1, uint32_t Arg2);
+ void __sanitizer_cov_trace_cmp8(uint64_t Arg1, uint64_t Arg2);
+
+ // Called before a switch statement.
+ // Val is the switch operand.
+ // Cases[0] is the number of case constants.
+ // Cases[1] is the size of Val in bits.
+ // Cases[2:] are the case constants.
+ void __sanitizer_cov_trace_switch(uint64_t Val, uint64_t *Cases);
+
+ // Called before a division statement.
+ // Val is the second argument of division.
+ void __sanitizer_cov_trace_div4(uint32_t Val);
+ void __sanitizer_cov_trace_div8(uint64_t Val);
+
+ // Called before a GetElemementPtr (GEP) instruction
+ // for every non-constant array index.
+ void __sanitizer_cov_trace_gep(uintptr_t Idx);
+
+
+This interface is a subject to change.
+
+Default implementation
+======================
+
+The sanitizer run-time (AddressSanitizer, MemorySanitizer, etc) provide a
+default implementations of some of the coverage callbacks.
+You may use this implementation to dump the coverage on disk at the process
+exit.
+
+Example:
+
+.. code-block:: console
+
+ % cat -n cov.cc
+ 1 #include <stdio.h>
+ 2 __attribute__((noinline))
+ 3 void foo() { printf("foo\n"); }
+ 4
+ 5 int main(int argc, char **argv) {
+ 6 if (argc == 2)
+ 7 foo();
+ 8 printf("main\n");
+ 9 }
+ % clang++ -g cov.cc -fsanitize=address -fsanitize-coverage=trace-pc-guard
+ % ASAN_OPTIONS=coverage=1 ./a.out; wc -c *.sancov
+ main
+ SanitizerCoverage: ./a.out.7312.sancov 2 PCs written
+ 24 a.out.7312.sancov
+ % ASAN_OPTIONS=coverage=1 ./a.out foo ; wc -c *.sancov
+ foo
+ main
+ SanitizerCoverage: ./a.out.7316.sancov 3 PCs written
+ 24 a.out.7312.sancov
+ 32 a.out.7316.sancov
+
+Every time you run an executable instrumented with SanitizerCoverage
+one ``*.sancov`` file is created during the process shutdown.
+If the executable is dynamically linked against instrumented DSOs,
+one ``*.sancov`` file will be also created for every DSO.
+
+Sancov data format
+------------------
+
+The format of ``*.sancov`` files is very simple: the first 8 bytes is the magic,
+one of ``0xC0BFFFFFFFFFFF64`` and ``0xC0BFFFFFFFFFFF32``. The last byte of the
+magic defines the size of the following offsets. The rest of the data is the
+offsets in the corresponding binary/DSO that were executed during the run.
+
+Sancov Tool
+-----------
+
+An simple ``sancov`` tool is provided to process coverage files.
+The tool is part of LLVM project and is currently supported only on Linux.
+It can handle symbolization tasks autonomously without any extra support
+from the environment. You need to pass .sancov files (named
+``<module_name>.<pid>.sancov`` and paths to all corresponding binary elf files.
+Sancov matches these files using module names and binaries file names.
+
+.. code-block:: console
+
+ USAGE: sancov [options] <action> (<binary file>|<.sancov file>)...
+
+ Action (required)
+ -print - Print coverage addresses
+ -covered-functions - Print all covered functions.
+ -not-covered-functions - Print all not covered functions.
+ -symbolize - Symbolizes the report.
+
+ Options
+ -blacklist=<string> - Blacklist file (sanitizer blacklist format).
+ -demangle - Print demangled function name.
+ -strip_path_prefix=<string> - Strip this prefix from file paths in reports
+
+
+Coverage Reports
+----------------
+
+**Experimental**
+
+``.sancov`` files do not contain enough information to generate a source-level
+coverage report. The missing information is contained
+in debug info of the binary. Thus the ``.sancov`` has to be symbolized
+to produce a ``.symcov`` file first:
+
+.. code-block:: console
+
+ sancov -symbolize my_program.123.sancov my_program > my_program.123.symcov
+
+The ``.symcov`` file can be browsed overlayed over the source code by
+running ``tools/sancov/coverage-report-server.py`` script that will start
+an HTTP server.
+
+Output directory
+----------------
+
+By default, .sancov files are created in the current working directory.
+This can be changed with ``ASAN_OPTIONS=coverage_dir=/path``:
+
+.. code-block:: console
+
+ % ASAN_OPTIONS="coverage=1:coverage_dir=/tmp/cov" ./a.out foo
+ % ls -l /tmp/cov/*sancov
+ -rw-r----- 1 kcc eng 4 Nov 27 12:21 a.out.22673.sancov
+ -rw-r----- 1 kcc eng 8 Nov 27 12:21 a.out.22679.sancov
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerSpecialCaseList.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerSpecialCaseList.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerSpecialCaseList.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerSpecialCaseList.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,79 @@
+===========================
+Sanitizer special case list
+===========================
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+This document describes the way to disable or alter the behavior of
+sanitizer tools for certain source-level entities by providing a special
+file at compile-time.
+
+Goal and usage
+==============
+
+User of sanitizer tools, such as :doc:`AddressSanitizer`, :doc:`ThreadSanitizer`
+or :doc:`MemorySanitizer` may want to disable or alter some checks for
+certain source-level entities to:
+
+* speedup hot function, which is known to be correct;
+* ignore a function that does some low-level magic (e.g. walks through the
+ thread stack, bypassing the frame boundaries);
+* ignore a known problem.
+
+To achieve this, user may create a file listing the entities they want to
+ignore, and pass it to clang at compile-time using
+``-fsanitize-blacklist`` flag. See :doc:`UsersManual` for details.
+
+Example
+=======
+
+.. code-block:: bash
+
+ $ cat foo.c
+ #include <stdlib.h>
+ void bad_foo() {
+ int *a = (int*)malloc(40);
+ a[10] = 1;
+ }
+ int main() { bad_foo(); }
+ $ cat blacklist.txt
+ # Ignore reports from bad_foo function.
+ fun:bad_foo
+ $ clang -fsanitize=address foo.c ; ./a.out
+ # AddressSanitizer prints an error report.
+ $ clang -fsanitize=address -fsanitize-blacklist=blacklist.txt foo.c ; ./a.out
+ # No error report here.
+
+Format
+======
+
+Each line contains an entity type, followed by a colon and a regular
+expression, specifying the names of the entities, optionally followed by
+an equals sign and a tool-specific category. Empty lines and lines starting
+with "#" are ignored. The meanining of ``*`` in regular expression for entity
+names is different - it is treated as in shell wildcarding. Two generic
+entity types are ``src`` and ``fun``, which allow user to add, respectively,
+source files and functions to special case list. Some sanitizer tools may
+introduce custom entity types - refer to tool-specific docs.
+
+.. code-block:: bash
+
+ # Lines starting with # are ignored.
+ # Turn off checks for the source file (use absolute path or path relative
+ # to the current working directory):
+ src:/path/to/source/file.c
+ # Turn off checks for a particular functions (use mangled names):
+ fun:MyFooBar
+ fun:_Z8MyFooBarv
+ # Extended regular expressions are supported:
+ fun:bad_(foo|bar)
+ src:bad_source[1-9].c
+ # Shell like usage of * is supported (* is treated as .*):
+ src:bad/sources/*
+ fun:*BadFunction*
+ # Specific sanitizer tools may introduce categories.
+ src:/special/path/*=special_sources
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerStats.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerStats.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerStats.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/SanitizerStats.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,62 @@
+==============
+SanitizerStats
+==============
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+The sanitizers support a simple mechanism for gathering profiling statistics
+to help understand the overhead associated with sanitizers.
+
+How to build and run
+====================
+
+SanitizerStats can currently only be used with :doc:`ControlFlowIntegrity`.
+In addition to ``-fsanitize=cfi*``, pass the ``-fsanitize-stats`` flag.
+This will cause the program to count the number of times that each control
+flow integrity check in the program fires.
+
+At run time, set the ``SANITIZER_STATS_PATH`` environment variable to direct
+statistics output to a file. The file will be written on process exit.
+The following substitutions will be applied to the environment variable:
+
+ - ``%b`` -- The executable basename.
+ - ``%p`` -- The process ID.
+
+You can also send the ``SIGUSR2`` signal to a process to make it write
+sanitizer statistics immediately.
+
+The ``sanstats`` program can be used to dump statistics. It takes as a
+command line argument the path to a statistics file produced by a program
+compiled with ``-fsanitize-stats``.
+
+The output of ``sanstats`` is in four columns, separated by spaces. The first
+column is the file and line number of the call site. The second column is
+the function name. The third column is the type of statistic gathered (in
+this case, the type of control flow integrity check). The fourth column is
+the call count.
+
+Example:
+
+.. code-block:: console
+
+ $ cat -n vcall.cc
+ 1 struct A {
+ 2 virtual void f() {}
+ 3 };
+ 4
+ 5 __attribute__((noinline)) void g(A *a) {
+ 6 a->f();
+ 7 }
+ 8
+ 9 int main() {
+ 10 A a;
+ 11 g(&a);
+ 12 }
+ $ clang++ -fsanitize=cfi -flto -fuse-ld=gold vcall.cc -fsanitize-stats -g
+ $ SANITIZER_STATS_PATH=a.stats ./a.out
+ $ sanstats a.stats
+ vcall.cc:6 _Z1gP1A cfi-vcall 1
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/SourceBasedCodeCoverage.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/SourceBasedCodeCoverage.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/SourceBasedCodeCoverage.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/SourceBasedCodeCoverage.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,295 @@
+==========================
+Source-based Code Coverage
+==========================
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+This document explains how to use clang's source-based code coverage feature.
+It's called "source-based" because it operates on AST and preprocessor
+information directly. This allows it to generate very precise coverage data.
+
+Clang ships two other code coverage implementations:
+
+* :doc:`SanitizerCoverage` - A low-overhead tool meant for use alongside the
+ various sanitizers. It can provide up to edge-level coverage.
+
+* gcov - A GCC-compatible coverage implementation which operates on DebugInfo.
+ This is enabled by ``-ftest-coverage`` or ``--coverage``.
+
+From this point onwards "code coverage" will refer to the source-based kind.
+
+The code coverage workflow
+==========================
+
+The code coverage workflow consists of three main steps:
+
+* Compiling with coverage enabled.
+
+* Running the instrumented program.
+
+* Creating coverage reports.
+
+The next few sections work through a complete, copy-'n-paste friendly example
+based on this program:
+
+.. code-block:: cpp
+
+ % cat <<EOF > foo.cc
+ #define BAR(x) ((x) || (x))
+ template <typename T> void foo(T x) {
+ for (unsigned I = 0; I < 10; ++I) { BAR(I); }
+ }
+ int main() {
+ foo<int>(0);
+ foo<float>(0);
+ return 0;
+ }
+ EOF
+
+Compiling with coverage enabled
+===============================
+
+To compile code with coverage enabled, pass ``-fprofile-instr-generate
+-fcoverage-mapping`` to the compiler:
+
+.. code-block:: console
+
+ # Step 1: Compile with coverage enabled.
+ % clang++ -fprofile-instr-generate -fcoverage-mapping foo.cc -o foo
+
+Note that linking together code with and without coverage instrumentation is
+supported. Uninstrumented code simply won't be accounted for in reports.
+
+Running the instrumented program
+================================
+
+The next step is to run the instrumented program. When the program exits it
+will write a **raw profile** to the path specified by the ``LLVM_PROFILE_FILE``
+environment variable. If that variable does not exist, the profile is written
+to ``default.profraw`` in the current directory of the program. If
+``LLVM_PROFILE_FILE`` contains a path to a non-existent directory, the missing
+directory structure will be created. Additionally, the following special
+**pattern strings** are rewritten:
+
+* "%p" expands out to the process ID.
+
+* "%h" expands out to the hostname of the machine running the program.
+
+* "%Nm" expands out to the instrumented binary's signature. When this pattern
+ is specified, the runtime creates a pool of N raw profiles which are used for
+ on-line profile merging. The runtime takes care of selecting a raw profile
+ from the pool, locking it, and updating it before the program exits. If N is
+ not specified (i.e the pattern is "%m"), it's assumed that ``N = 1``. N must
+ be between 1 and 9. The merge pool specifier can only occur once per filename
+ pattern.
+
+.. code-block:: console
+
+ # Step 2: Run the program.
+ % LLVM_PROFILE_FILE="foo.profraw" ./foo
+
+Creating coverage reports
+=========================
+
+Raw profiles have to be **indexed** before they can be used to generate
+coverage reports. This is done using the "merge" tool in ``llvm-profdata``
+(which can combine multiple raw profiles and index them at the same time):
+
+.. code-block:: console
+
+ # Step 3(a): Index the raw profile.
+ % llvm-profdata merge -sparse foo.profraw -o foo.profdata
+
+There are multiple different ways to render coverage reports. The simplest
+option is to generate a line-oriented report:
+
+.. code-block:: console
+
+ # Step 3(b): Create a line-oriented coverage report.
+ % llvm-cov show ./foo -instr-profile=foo.profdata
+
+This report includes a summary view as well as dedicated sub-views for
+templated functions and their instantiations. For our example program, we get
+distinct views for ``foo<int>(...)`` and ``foo<float>(...)``. If
+``-show-line-counts-or-regions`` is enabled, ``llvm-cov`` displays sub-line
+region counts (even in macro expansions):
+
+.. code-block:: none
+
+ 1| 20|#define BAR(x) ((x) || (x))
+ ^20 ^2
+ 2| 2|template <typename T> void foo(T x) {
+ 3| 22| for (unsigned I = 0; I < 10; ++I) { BAR(I); }
+ ^22 ^20 ^20^20
+ 4| 2|}
+ ------------------
+ | void foo<int>(int):
+ | 2| 1|template <typename T> void foo(T x) {
+ | 3| 11| for (unsigned I = 0; I < 10; ++I) { BAR(I); }
+ | ^11 ^10 ^10^10
+ | 4| 1|}
+ ------------------
+ | void foo<float>(int):
+ | 2| 1|template <typename T> void foo(T x) {
+ | 3| 11| for (unsigned I = 0; I < 10; ++I) { BAR(I); }
+ | ^11 ^10 ^10^10
+ | 4| 1|}
+ ------------------
+
+To generate a file-level summary of coverage statistics instead of a
+line-oriented report, try:
+
+.. code-block:: console
+
+ # Step 3(c): Create a coverage summary.
+ % llvm-cov report ./foo -instr-profile=foo.profdata
+ Filename Regions Missed Regions Cover Functions Missed Functions Executed Lines Missed Lines Cover
+ --------------------------------------------------------------------------------------------------------------------------------------
+ /tmp/foo.cc 13 0 100.00% 3 0 100.00% 13 0 100.00%
+ --------------------------------------------------------------------------------------------------------------------------------------
+ TOTAL 13 0 100.00% 3 0 100.00% 13 0 100.00%
+
+The ``llvm-cov`` tool supports specifying a custom demangler, writing out
+reports in a directory structure, and generating html reports. For the full
+list of options, please refer to the `command guide
+<http://llvm.org/docs/CommandGuide/llvm-cov.html>`_.
+
+A few final notes:
+
+* The ``-sparse`` flag is optional but can result in dramatically smaller
+ indexed profiles. This option should not be used if the indexed profile will
+ be reused for PGO.
+
+* Raw profiles can be discarded after they are indexed. Advanced use of the
+ profile runtime library allows an instrumented program to merge profiling
+ information directly into an existing raw profile on disk. The details are
+ out of scope.
+
+* The ``llvm-profdata`` tool can be used to merge together multiple raw or
+ indexed profiles. To combine profiling data from multiple runs of a program,
+ try e.g:
+
+ .. code-block:: console
+
+ % llvm-profdata merge -sparse foo1.profraw foo2.profdata -o foo3.profdata
+
+Exporting coverage data
+=======================
+
+Coverage data can be exported into JSON using the ``llvm-cov export``
+sub-command. There is a comprehensive reference which defines the structure of
+the exported data at a high level in the llvm-cov source code.
+
+Interpreting reports
+====================
+
+There are four statistics tracked in a coverage summary:
+
+* Function coverage is the percentage of functions which have been executed at
+ least once. A function is considered to be executed if any of its
+ instantiations are executed.
+
+* Instantiation coverage is the percentage of function instantiations which
+ have been executed at least once. Template functions and static inline
+ functions from headers are two kinds of functions which may have multiple
+ instantiations.
+
+* Line coverage is the percentage of code lines which have been executed at
+ least once. Only executable lines within function bodies are considered to be
+ code lines.
+
+* Region coverage is the percentage of code regions which have been executed at
+ least once. A code region may span multiple lines (e.g in a large function
+ body with no control flow). However, it's also possible for a single line to
+ contain multiple code regions (e.g in "return x || y && z").
+
+Of these four statistics, function coverage is usually the least granular while
+region coverage is the most granular. The project-wide totals for each
+statistic are listed in the summary.
+
+Format compatibility guarantees
+===============================
+
+* There are no backwards or forwards compatibility guarantees for the raw
+ profile format. Raw profiles may be dependent on the specific compiler
+ revision used to generate them. It's inadvisable to store raw profiles for
+ long periods of time.
+
+* Tools must retain **backwards** compatibility with indexed profile formats.
+ These formats are not forwards-compatible: i.e, a tool which uses format
+ version X will not be able to understand format version (X+k).
+
+* Tools must also retain **backwards** compatibility with the format of the
+ coverage mappings emitted into instrumented binaries. These formats are not
+ forwards-compatible.
+
+* The JSON coverage export format has a (major, minor, patch) version triple.
+ Only a major version increment indicates a backwards-incompatible change. A
+ minor version increment is for added functionality, and patch version
+ increments are for bugfixes.
+
+Using the profiling runtime without static initializers
+=======================================================
+
+By default the compiler runtime uses a static initializer to determine the
+profile output path and to register a writer function. To collect profiles
+without using static initializers, do this manually:
+
+* Export a ``int __llvm_profile_runtime`` symbol from each instrumented shared
+ library and executable. When the linker finds a definition of this symbol, it
+ knows to skip loading the object which contains the profiling runtime's
+ static initializer.
+
+* Forward-declare ``void __llvm_profile_initialize_file(void)`` and call it
+ once from each instrumented executable. This function parses
+ ``LLVM_PROFILE_FILE``, sets the output path, and truncates any existing files
+ at that path. To get the same behavior without truncating existing files,
+ pass a filename pattern string to ``void __llvm_profile_set_filename(char
+ *)``. These calls can be placed anywhere so long as they precede all calls
+ to ``__llvm_profile_write_file``.
+
+* Forward-declare ``int __llvm_profile_write_file(void)`` and call it to write
+ out a profile. This function returns 0 when it succeeds, and a non-zero value
+ otherwise. Calling this function multiple times appends profile data to an
+ existing on-disk raw profile.
+
+In C++ files, declare these as ``extern "C"``.
+
+Collecting coverage reports for the llvm project
+================================================
+
+To prepare a coverage report for llvm (and any of its sub-projects), add
+``-DLLVM_BUILD_INSTRUMENTED_COVERAGE=On`` to the cmake configuration. Raw
+profiles will be written to ``$BUILD_DIR/profiles/``. To prepare an html
+report, run ``llvm/utils/prepare-code-coverage-artifact.py``.
+
+To specify an alternate directory for raw profiles, use
+``-DLLVM_PROFILE_DATA_DIR``. To change the size of the profile merge pool, use
+``-DLLVM_PROFILE_MERGE_POOL_SIZE``.
+
+Drawbacks and limitations
+=========================
+
+* Prior to version 2.26, the GNU binutils BFD linker is not able link programs
+ compiled with ``-fcoverage-mapping`` in its ``--gc-sections`` mode. Possible
+ workarounds include disabling ``--gc-sections``, upgrading to a newer version
+ of BFD, or using the Gold linker.
+
+* Code coverage does not handle unpredictable changes in control flow or stack
+ unwinding in the presence of exceptions precisely. Consider the following
+ function:
+
+ .. code-block:: cpp
+
+ int f() {
+ may_throw();
+ return 0;
+ }
+
+ If the call to ``may_throw()`` propagates an exception into ``f``, the code
+ coverage tool may mark the ``return`` statement as executed even though it is
+ not. A call to ``longjmp()`` can have similar effects.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThinLTO.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThinLTO.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThinLTO.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThinLTO.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,205 @@
+=======
+ThinLTO
+=======
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+*ThinLTO* compilation is a new type of LTO that is both scalable and
+incremental. *LTO* (Link Time Optimization) achieves better
+runtime performance through whole-program analysis and cross-module
+optimization. However, monolithic LTO implements this by merging all
+input into a single module, which is not scalable
+in time or memory, and also prevents fast incremental compiles.
+
+In ThinLTO mode, as with regular LTO, clang emits LLVM bitcode after the
+compile phase. The ThinLTO bitcode is augmented with a compact summary
+of the module. During the link step, only the summaries are read and
+merged into a combined summary index, which includes an index of function
+locations for later cross-module function importing. Fast and efficient
+whole-program analysis is then performed on the combined summary index.
+
+However, all transformations, including function importing, occur
+later when the modules are optimized in fully parallel backends.
+By default, linkers_ that support ThinLTO are set up to launch
+the ThinLTO backends in threads. So the usage model is not affected
+as the distinction between the fast serial thin link step and the backends
+is transparent to the user.
+
+For more information on the ThinLTO design and current performance,
+see the LLVM blog post `ThinLTO: Scalable and Incremental LTO
+<http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html>`_.
+While tuning is still in progress, results in the blog post show that
+ThinLTO already performs well compared to LTO, in many cases matching
+the performance improvement.
+
+Current Status
+==============
+
+Clang/LLVM
+----------
+.. _compiler:
+
+The 3.9 release of clang includes ThinLTO support. However, ThinLTO
+is under active development, and new features, improvements and bugfixes
+are being added for the next release. For the latest ThinLTO support,
+`build a recent version of clang and LLVM
+<http://llvm.org/docs/CMake.html>`_.
+
+Linkers
+-------
+.. _linkers:
+.. _linker:
+
+ThinLTO is currently supported for the following linkers:
+
+- **gold (via the gold-plugin)**:
+ Similar to monolithic LTO, this requires using
+ a `gold linker configured with plugins enabled
+ <http://llvm.org/docs/GoldPlugin.html>`_.
+- **ld64**:
+ Starting with `Xcode 8 <https://developer.apple.com/xcode/>`_.
+- **lld**:
+ Starting with r284050 (ELF only).
+
+Usage
+=====
+
+Basic
+-----
+
+To utilize ThinLTO, simply add the -flto=thin option to compile and link. E.g.
+
+.. code-block:: console
+
+ % clang -flto=thin -O2 file1.c file2.c -c
+ % clang -flto=thin -O2 file1.o file2.o -o a.out
+
+As mentioned earlier, by default the linkers will launch the ThinLTO backend
+threads in parallel, passing the resulting native object files back to the
+linker for the final native link. As such, the usage model the same as
+non-LTO.
+
+With gold, if you see an error during the link of the form:
+
+.. code-block:: console
+
+ /usr/bin/ld: error: /path/to/clang/bin/../lib/LLVMgold.so: could not load plugin library: /path/to/clang/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory
+
+Then either gold was not configured with plugins enabled, or clang
+was not built with ``-DLLVM_BINUTILS_INCDIR`` set properly. See
+the instructions for the
+`LLVM gold plugin <http://llvm.org/docs/GoldPlugin.html#how-to-build-it>`_.
+
+Controlling Backend Parallelism
+-------------------------------
+.. _parallelism:
+
+By default, the ThinLTO link step will launch up to
+``std::thread::hardware_concurrency`` number of threads in parallel.
+For machines with hyper-threading, this is the total number of
+virtual cores. For some applications and machine configurations this
+may be too aggressive, in which case the amount of parallelism can
+be reduced to ``N`` via:
+
+- gold:
+ ``-Wl,-plugin-opt,jobs=N``
+- ld64:
+ ``-Wl,-mllvm,-threads=N``
+- lld:
+ ``-Wl,--thinlto-jobs=N``
+
+Incremental
+-----------
+.. _incremental:
+
+ThinLTO supports fast incremental builds through the use of a cache,
+which currently must be enabled through a linker option.
+
+- gold (as of LLVM r279883):
+ ``-Wl,-plugin-opt,cache-dir=/path/to/cache``
+- ld64 (support in clang 3.9 and Xcode 8):
+ ``-Wl,-cache_path_lto,/path/to/cache``
+- lld (as of LLVM r296702):
+ ``-Wl,--thinlto-cache-dir=/path/to/cache``
+
+Cache Pruning
+-------------
+
+To help keep the size of the cache under control, ThinLTO supports cache
+pruning. Cache pruning is supported with ld64 and ELF lld, but currently only
+ELF lld allows you to control the policy with a policy string. The cache
+policy must be specified with a linker option.
+
+- ELF lld (as of LLVM r298036):
+ ``-Wl,--thinlto-cache-policy,POLICY``
+
+A policy string is a series of key-value pairs separated by ``:`` characters.
+Possible key-value pairs are:
+
+- ``cache_size=X%``: The maximum size for the cache directory is ``X`` percent
+ of the available space on the the disk. Set to 100 to indicate no limit,
+ 50 to indicate that the cache size will not be left over half the available
+ disk space. A value over 100 is invalid. A value of 0 disables the percentage
+ size-based pruning. The default is 75%.
+
+- ``cache_size_bytes=X``, ``cache_size_bytes=Xk``, ``cache_size_bytes=Xm``,
+ ``cache_size_bytes=Xg``:
+ Sets the maximum size for the cache directory to ``X`` bytes (or KB, MB,
+ GB respectively). A value over the amount of available space on the disk
+ will be reduced to the amount of available space. A value of 0 disables
+ the byte size-based pruning. The default is no byte size-based pruning.
+
+ Note that ThinLTO will apply both size-based pruning policies simultaneously,
+ and changing one does not affect the other. For example, a policy of
+ ``cache_size_bytes=1g`` on its own will cause both the 1GB and default 75%
+ policies to be applied unless the default ``cache_size`` is overridden.
+
+- ``prune_after=Xs``, ``prune_after=Xm``, ``prune_after=Xh``: Sets the
+ expiration time for cache files to ``X`` seconds (or minutes, hours
+ respectively). When a file hasn't been accessed for ``prune_after`` seconds,
+ it is removed from the cache. A value of 0 disables the expiration-based
+ pruning. The default is 1 week.
+
+- ``prune_interval=Xs``, ``prune_interval=Xm``, ``prune_interval=Xh``:
+ Sets the pruning interval to ``X`` seconds (or minutes, hours
+ respectively). This is intended to be used to avoid scanning the directory
+ too often. It does not impact the decision of which files to prune. A
+ value of 0 forces the scan to occur. The default is every 20 minutes.
+
+Clang Bootstrap
+---------------
+
+To bootstrap clang/LLVM with ThinLTO, follow these steps:
+
+1. The host compiler_ must be a version of clang that supports ThinLTO.
+#. The host linker_ must support ThinLTO (and in the case of gold, must be
+ `configured with plugins enabled <http://llvm.org/docs/GoldPlugin.html>`_.
+#. Use the following additional `CMake variables
+ <http://llvm.org/docs/CMake.html#options-and-variables>`_
+ when configuring the bootstrap compiler build:
+
+ * ``-DLLVM_ENABLE_LTO=Thin``
+ * ``-DLLVM_PARALLEL_LINK_JOBS=1``
+ (since the ThinLTO link invokes parallel backend jobs)
+ * ``-DCMAKE_C_COMPILER=/path/to/host/clang``
+ * ``-DCMAKE_CXX_COMPILER=/path/to/host/clang++``
+ * ``-DCMAKE_RANLIB=/path/to/host/llvm-ranlib``
+ * ``-DCMAKE_AR=/path/to/host/llvm-ar``
+
+#. To use additional linker arguments for controlling the backend
+ parallelism_ or enabling incremental_ builds of the bootstrap compiler,
+ after configuring the build, modify the resulting CMakeCache.txt file in the
+ build directory. Specify any additional linker options after
+ ``CMAKE_EXE_LINKER_FLAGS:STRING=``. Note the configure may fail if
+ linker plugin options are instead specified directly in the previous step.
+
+More Information
+================
+
+* From LLVM project blog:
+ `ThinLTO: Scalable and Incremental LTO
+ <http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html>`_
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThreadSafetyAnalysis.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThreadSafetyAnalysis.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThreadSafetyAnalysis.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThreadSafetyAnalysis.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,948 @@
+
+======================
+Thread Safety Analysis
+======================
+
+Introduction
+============
+
+Clang Thread Safety Analysis is a C++ language extension which warns about
+potential race conditions in code. The analysis is completely static (i.e.
+compile-time); there is no run-time overhead. The analysis is still
+under active development, but it is mature enough to be deployed in an
+industrial setting. It is being developed by Google, in collaboration with
+CERT/SEI, and is used extensively in Google's internal code base.
+
+Thread safety analysis works very much like a type system for multi-threaded
+programs. In addition to declaring the *type* of data (e.g. ``int``, ``float``,
+etc.), the programmer can (optionally) declare how access to that data is
+controlled in a multi-threaded environment. For example, if ``foo`` is
+*guarded by* the mutex ``mu``, then the analysis will issue a warning whenever
+a piece of code reads or writes to ``foo`` without first locking ``mu``.
+Similarly, if there are particular routines that should only be called by
+the GUI thread, then the analysis will warn if other threads call those
+routines.
+
+Getting Started
+----------------
+
+.. code-block:: c++
+
+ #include "mutex.h"
+
+ class BankAccount {
+ private:
+ Mutex mu;
+ int balance GUARDED_BY(mu);
+
+ void depositImpl(int amount) {
+ balance += amount; // WARNING! Cannot write balance without locking mu.
+ }
+
+ void withdrawImpl(int amount) REQUIRES(mu) {
+ balance -= amount; // OK. Caller must have locked mu.
+ }
+
+ public:
+ void withdraw(int amount) {
+ mu.Lock();
+ withdrawImpl(amount); // OK. We've locked mu.
+ } // WARNING! Failed to unlock mu.
+
+ void transferFrom(BankAccount& b, int amount) {
+ mu.Lock();
+ b.withdrawImpl(amount); // WARNING! Calling withdrawImpl() requires locking b.mu.
+ depositImpl(amount); // OK. depositImpl() has no requirements.
+ mu.Unlock();
+ }
+ };
+
+This example demonstrates the basic concepts behind the analysis. The
+``GUARDED_BY`` attribute declares that a thread must lock ``mu`` before it can
+read or write to ``balance``, thus ensuring that the increment and decrement
+operations are atomic. Similarly, ``REQUIRES`` declares that
+the calling thread must lock ``mu`` before calling ``withdrawImpl``.
+Because the caller is assumed to have locked ``mu``, it is safe to modify
+``balance`` within the body of the method.
+
+The ``depositImpl()`` method does not have ``REQUIRES``, so the
+analysis issues a warning. Thread safety analysis is not inter-procedural, so
+caller requirements must be explicitly declared.
+There is also a warning in ``transferFrom()``, because although the method
+locks ``this->mu``, it does not lock ``b.mu``. The analysis understands
+that these are two separate mutexes, in two different objects.
+
+Finally, there is a warning in the ``withdraw()`` method, because it fails to
+unlock ``mu``. Every lock must have a corresponding unlock, and the analysis
+will detect both double locks, and double unlocks. A function is allowed to
+acquire a lock without releasing it, (or vice versa), but it must be annotated
+as such (using ``ACQUIRE``/``RELEASE``).
+
+
+Running The Analysis
+--------------------
+
+To run the analysis, simply compile with the ``-Wthread-safety`` flag, e.g.
+
+.. code-block:: bash
+
+ clang -c -Wthread-safety example.cpp
+
+Note that this example assumes the presence of a suitably annotated
+:ref:`mutexheader` that declares which methods perform locking,
+unlocking, and so on.
+
+
+Basic Concepts: Capabilities
+============================
+
+Thread safety analysis provides a way of protecting *resources* with
+*capabilities*. A resource is either a data member, or a function/method
+that provides access to some underlying resource. The analysis ensures that
+the calling thread cannot access the *resource* (i.e. call the function, or
+read/write the data) unless it has the *capability* to do so.
+
+Capabilities are associated with named C++ objects which declare specific
+methods to acquire and release the capability. The name of the object serves
+to identify the capability. The most common example is a mutex. For example,
+if ``mu`` is a mutex, then calling ``mu.Lock()`` causes the calling thread
+to acquire the capability to access data that is protected by ``mu``. Similarly,
+calling ``mu.Unlock()`` releases that capability.
+
+A thread may hold a capability either *exclusively* or *shared*. An exclusive
+capability can be held by only one thread at a time, while a shared capability
+can be held by many threads at the same time. This mechanism enforces a
+multiple-reader, single-writer pattern. Write operations to protected data
+require exclusive access, while read operations require only shared access.
+
+At any given moment during program execution, a thread holds a specific set of
+capabilities (e.g. the set of mutexes that it has locked.) These act like keys
+or tokens that allow the thread to access a given resource. Just like physical
+security keys, a thread cannot make copy of a capability, nor can it destroy
+one. A thread can only release a capability to another thread, or acquire one
+from another thread. The annotations are deliberately agnostic about the
+exact mechanism used to acquire and release capabilities; it assumes that the
+underlying implementation (e.g. the Mutex implementation) does the handoff in
+an appropriate manner.
+
+The set of capabilities that are actually held by a given thread at a given
+point in program execution is a run-time concept. The static analysis works
+by calculating an approximation of that set, called the *capability
+environment*. The capability environment is calculated for every program point,
+and describes the set of capabilities that are statically known to be held, or
+not held, at that particular point. This environment is a conservative
+approximation of the full set of capabilities that will actually held by a
+thread at run-time.
+
+
+Reference Guide
+===============
+
+The thread safety analysis uses attributes to declare threading constraints.
+Attributes must be attached to named declarations, such as classes, methods,
+and data members. Users are *strongly advised* to define macros for the various
+attributes; example definitions can be found in :ref:`mutexheader`, below.
+The following documentation assumes the use of macros.
+
+For historical reasons, prior versions of thread safety used macro names that
+were very lock-centric. These macros have since been renamed to fit a more
+general capability model. The prior names are still in use, and will be
+mentioned under the tag *previously* where appropriate.
+
+
+GUARDED_BY(c) and PT_GUARDED_BY(c)
+----------------------------------
+
+``GUARDED_BY`` is an attribute on data members, which declares that the data
+member is protected by the given capability. Read operations on the data
+require shared access, while write operations require exclusive access.
+
+``PT_GUARDED_BY`` is similar, but is intended for use on pointers and smart
+pointers. There is no constraint on the data member itself, but the *data that
+it points to* is protected by the given capability.
+
+.. code-block:: c++
+
+ Mutex mu;
+ int *p1 GUARDED_BY(mu);
+ int *p2 PT_GUARDED_BY(mu);
+ unique_ptr<int> p3 PT_GUARDED_BY(mu);
+
+ void test() {
+ p1 = 0; // Warning!
+
+ *p2 = 42; // Warning!
+ p2 = new int; // OK.
+
+ *p3 = 42; // Warning!
+ p3.reset(new int); // OK.
+ }
+
+
+REQUIRES(...), REQUIRES_SHARED(...)
+-----------------------------------
+
+*Previously*: ``EXCLUSIVE_LOCKS_REQUIRED``, ``SHARED_LOCKS_REQUIRED``
+
+``REQUIRES`` is an attribute on functions or methods, which
+declares that the calling thread must have exclusive access to the given
+capabilities. More than one capability may be specified. The capabilities
+must be held on entry to the function, *and must still be held on exit*.
+
+``REQUIRES_SHARED`` is similar, but requires only shared access.
+
+.. code-block:: c++
+
+ Mutex mu1, mu2;
+ int a GUARDED_BY(mu1);
+ int b GUARDED_BY(mu2);
+
+ void foo() REQUIRES(mu1, mu2) {
+ a = 0;
+ b = 0;
+ }
+
+ void test() {
+ mu1.Lock();
+ foo(); // Warning! Requires mu2.
+ mu1.Unlock();
+ }
+
+
+ACQUIRE(...), ACQUIRE_SHARED(...), RELEASE(...), RELEASE_SHARED(...)
+--------------------------------------------------------------------
+
+*Previously*: ``EXCLUSIVE_LOCK_FUNCTION``, ``SHARED_LOCK_FUNCTION``,
+``UNLOCK_FUNCTION``
+
+``ACQUIRE`` is an attribute on functions or methods, which
+declares that the function acquires a capability, but does not release it. The
+caller must not hold the given capability on entry, and it will hold the
+capability on exit. ``ACQUIRE_SHARED`` is similar.
+
+``RELEASE`` and ``RELEASE_SHARED`` declare that the function releases the given
+capability. The caller must hold the capability on entry, and will no longer
+hold it on exit. It does not matter whether the given capability is shared or
+exclusive.
+
+.. code-block:: c++
+
+ Mutex mu;
+ MyClass myObject GUARDED_BY(mu);
+
+ void lockAndInit() ACQUIRE(mu) {
+ mu.Lock();
+ myObject.init();
+ }
+
+ void cleanupAndUnlock() RELEASE(mu) {
+ myObject.cleanup();
+ } // Warning! Need to unlock mu.
+
+ void test() {
+ lockAndInit();
+ myObject.doSomething();
+ cleanupAndUnlock();
+ myObject.doSomething(); // Warning, mu is not locked.
+ }
+
+If no argument is passed to ``ACQUIRE`` or ``RELEASE``, then the argument is
+assumed to be ``this``, and the analysis will not check the body of the
+function. This pattern is intended for use by classes which hide locking
+details behind an abstract interface. For example:
+
+.. code-block:: c++
+
+ template <class T>
+ class CAPABILITY("mutex") Container {
+ private:
+ Mutex mu;
+ T* data;
+
+ public:
+ // Hide mu from public interface.
+ void Lock() ACQUIRE() { mu.Lock(); }
+ void Unlock() RELEASE() { mu.Unlock(); }
+
+ T& getElem(int i) { return data[i]; }
+ };
+
+ void test() {
+ Container<int> c;
+ c.Lock();
+ int i = c.getElem(0);
+ c.Unlock();
+ }
+
+
+EXCLUDES(...)
+-------------
+
+*Previously*: ``LOCKS_EXCLUDED``
+
+``EXCLUDES`` is an attribute on functions or methods, which declares that
+the caller must *not* hold the given capabilities. This annotation is
+used to prevent deadlock. Many mutex implementations are not re-entrant, so
+deadlock can occur if the function acquires the mutex a second time.
+
+.. code-block:: c++
+
+ Mutex mu;
+ int a GUARDED_BY(mu);
+
+ void clear() EXCLUDES(mu) {
+ mu.Lock();
+ a = 0;
+ mu.Unlock();
+ }
+
+ void reset() {
+ mu.Lock();
+ clear(); // Warning! Caller cannot hold 'mu'.
+ mu.Unlock();
+ }
+
+Unlike ``REQUIRES``, ``EXCLUDES`` is optional. The analysis will not issue a
+warning if the attribute is missing, which can lead to false negatives in some
+cases. This issue is discussed further in :ref:`negative`.
+
+
+NO_THREAD_SAFETY_ANALYSIS
+-------------------------
+
+``NO_THREAD_SAFETY_ANALYSIS`` is an attribute on functions or methods, which
+turns off thread safety checking for that method. It provides an escape hatch
+for functions which are either (1) deliberately thread-unsafe, or (2) are
+thread-safe, but too complicated for the analysis to understand. Reasons for
+(2) will be described in the :ref:`limitations`, below.
+
+.. code-block:: c++
+
+ class Counter {
+ Mutex mu;
+ int a GUARDED_BY(mu);
+
+ void unsafeIncrement() NO_THREAD_SAFETY_ANALYSIS { a++; }
+ };
+
+Unlike the other attributes, NO_THREAD_SAFETY_ANALYSIS is not part of the
+interface of a function, and should thus be placed on the function definition
+(in the ``.cc`` or ``.cpp`` file) rather than on the function declaration
+(in the header).
+
+
+RETURN_CAPABILITY(c)
+--------------------
+
+*Previously*: ``LOCK_RETURNED``
+
+``RETURN_CAPABILITY`` is an attribute on functions or methods, which declares
+that the function returns a reference to the given capability. It is used to
+annotate getter methods that return mutexes.
+
+.. code-block:: c++
+
+ class MyClass {
+ private:
+ Mutex mu;
+ int a GUARDED_BY(mu);
+
+ public:
+ Mutex* getMu() RETURN_CAPABILITY(mu) { return μ }
+
+ // analysis knows that getMu() == mu
+ void clear() REQUIRES(getMu()) { a = 0; }
+ };
+
+
+ACQUIRED_BEFORE(...), ACQUIRED_AFTER(...)
+-----------------------------------------
+
+``ACQUIRED_BEFORE`` and ``ACQUIRED_AFTER`` are attributes on member
+declarations, specifically declarations of mutexes or other capabilities.
+These declarations enforce a particular order in which the mutexes must be
+acquired, in order to prevent deadlock.
+
+.. code-block:: c++
+
+ Mutex m1;
+ Mutex m2 ACQUIRED_AFTER(m1);
+
+ // Alternative declaration
+ // Mutex m2;
+ // Mutex m1 ACQUIRED_BEFORE(m2);
+
+ void foo() {
+ m2.Lock();
+ m1.Lock(); // Warning! m2 must be acquired after m1.
+ m1.Unlock();
+ m2.Unlock();
+ }
+
+
+CAPABILITY(<string>)
+--------------------
+
+*Previously*: ``LOCKABLE``
+
+``CAPABILITY`` is an attribute on classes, which specifies that objects of the
+class can be used as a capability. The string argument specifies the kind of
+capability in error messages, e.g. ``"mutex"``. See the ``Container`` example
+given above, or the ``Mutex`` class in :ref:`mutexheader`.
+
+
+SCOPED_CAPABILITY
+-----------------
+
+*Previously*: ``SCOPED_LOCKABLE``
+
+``SCOPED_CAPABILITY`` is an attribute on classes that implement RAII-style
+locking, in which a capability is acquired in the constructor, and released in
+the destructor. Such classes require special handling because the constructor
+and destructor refer to the capability via different names; see the
+``MutexLocker`` class in :ref:`mutexheader`, below.
+
+
+TRY_ACQUIRE(<bool>, ...), TRY_ACQUIRE_SHARED(<bool>, ...)
+---------------------------------------------------------
+
+*Previously:* ``EXCLUSIVE_TRYLOCK_FUNCTION``, ``SHARED_TRYLOCK_FUNCTION``
+
+These are attributes on a function or method that tries to acquire the given
+capability, and returns a boolean value indicating success or failure.
+The first argument must be ``true`` or ``false``, to specify which return value
+indicates success, and the remaining arguments are interpreted in the same way
+as ``ACQUIRE``. See :ref:`mutexheader`, below, for example uses.
+
+
+ASSERT_CAPABILITY(...) and ASSERT_SHARED_CAPABILITY(...)
+--------------------------------------------------------
+
+*Previously:* ``ASSERT_EXCLUSIVE_LOCK``, ``ASSERT_SHARED_LOCK``
+
+These are attributes on a function or method that does a run-time test to see
+whether the calling thread holds the given capability. The function is assumed
+to fail (no return) if the capability is not held. See :ref:`mutexheader`,
+below, for example uses.
+
+
+GUARDED_VAR and PT_GUARDED_VAR
+------------------------------
+
+Use of these attributes has been deprecated.
+
+
+Warning flags
+-------------
+
+* ``-Wthread-safety``: Umbrella flag which turns on the following three:
+
+ + ``-Wthread-safety-attributes``: Sanity checks on attribute syntax.
+ + ``-Wthread-safety-analysis``: The core analysis.
+ + ``-Wthread-safety-precise``: Requires that mutex expressions match precisely.
+ This warning can be disabled for code which has a lot of aliases.
+ + ``-Wthread-safety-reference``: Checks when guarded members are passed by reference.
+
+
+:ref:`negative` are an experimental feature, which are enabled with:
+
+* ``-Wthread-safety-negative``: Negative capabilities. Off by default.
+
+When new features and checks are added to the analysis, they can often introduce
+additional warnings. Those warnings are initially released as *beta* warnings
+for a period of time, after which they are migrated into the standard analysis.
+
+* ``-Wthread-safety-beta``: New features. Off by default.
+
+
+.. _negative:
+
+Negative Capabilities
+=====================
+
+Thread Safety Analysis is designed to prevent both race conditions and
+deadlock. The GUARDED_BY and REQUIRES attributes prevent race conditions, by
+ensuring that a capability is held before reading or writing to guarded data,
+and the EXCLUDES attribute prevents deadlock, by making sure that a mutex is
+*not* held.
+
+However, EXCLUDES is an optional attribute, and does not provide the same
+safety guarantee as REQUIRES. In particular:
+
+ * A function which acquires a capability does not have to exclude it.
+ * A function which calls a function that excludes a capability does not
+ have transitively exclude that capability.
+
+As a result, EXCLUDES can easily produce false negatives:
+
+.. code-block:: c++
+
+ class Foo {
+ Mutex mu;
+
+ void foo() {
+ mu.Lock();
+ bar(); // No warning.
+ baz(); // No warning.
+ mu.Unlock();
+ }
+
+ void bar() { // No warning. (Should have EXCLUDES(mu)).
+ mu.Lock();
+ // ...
+ mu.Unlock();
+ }
+
+ void baz() {
+ bif(); // No warning. (Should have EXCLUDES(mu)).
+ }
+
+ void bif() EXCLUDES(mu);
+ };
+
+
+Negative requirements are an alternative EXCLUDES that provide
+a stronger safety guarantee. A negative requirement uses the REQUIRES
+attribute, in conjunction with the ``!`` operator, to indicate that a capability
+should *not* be held.
+
+For example, using ``REQUIRES(!mu)`` instead of ``EXCLUDES(mu)`` will produce
+the appropriate warnings:
+
+.. code-block:: c++
+
+ class FooNeg {
+ Mutex mu;
+
+ void foo() REQUIRES(!mu) { // foo() now requires !mu.
+ mu.Lock();
+ bar();
+ baz();
+ mu.Unlock();
+ }
+
+ void bar() {
+ mu.Lock(); // WARNING! Missing REQUIRES(!mu).
+ // ...
+ mu.Unlock();
+ }
+
+ void baz() {
+ bif(); // WARNING! Missing REQUIRES(!mu).
+ }
+
+ void bif() REQUIRES(!mu);
+ };
+
+
+Negative requirements are an experimental feature which is off by default,
+because it will produce many warnings in existing code. It can be enabled
+by passing ``-Wthread-safety-negative``.
+
+
+.. _faq:
+
+Frequently Asked Questions
+==========================
+
+(Q) Should I put attributes in the header file, or in the .cc/.cpp/.cxx file?
+
+(A) Attributes are part of the formal interface of a function, and should
+always go in the header, where they are visible to anything that includes
+the header. Attributes in the .cpp file are not visible outside of the
+immediate translation unit, which leads to false negatives and false positives.
+
+
+(Q) "*Mutex is not locked on every path through here?*" What does that mean?
+
+(A) See :ref:`conditional_locks`, below.
+
+
+.. _limitations:
+
+Known Limitations
+=================
+
+Lexical scope
+-------------
+
+Thread safety attributes contain ordinary C++ expressions, and thus follow
+ordinary C++ scoping rules. In particular, this means that mutexes and other
+capabilities must be declared before they can be used in an attribute.
+Use-before-declaration is okay within a single class, because attributes are
+parsed at the same time as method bodies. (C++ delays parsing of method bodies
+until the end of the class.) However, use-before-declaration is not allowed
+between classes, as illustrated below.
+
+.. code-block:: c++
+
+ class Foo;
+
+ class Bar {
+ void bar(Foo* f) REQUIRES(f->mu); // Error: mu undeclared.
+ };
+
+ class Foo {
+ Mutex mu;
+ };
+
+
+Private Mutexes
+---------------
+
+Good software engineering practice dictates that mutexes should be private
+members, because the locking mechanism used by a thread-safe class is part of
+its internal implementation. However, private mutexes can sometimes leak into
+the public interface of a class.
+Thread safety attributes follow normal C++ access restrictions, so if ``mu``
+is a private member of ``c``, then it is an error to write ``c.mu`` in an
+attribute.
+
+One workaround is to (ab)use the ``RETURN_CAPABILITY`` attribute to provide a
+public *name* for a private mutex, without actually exposing the underlying
+mutex. For example:
+
+.. code-block:: c++
+
+ class MyClass {
+ private:
+ Mutex mu;
+
+ public:
+ // For thread safety analysis only. Does not actually return mu.
+ Mutex* getMu() RETURN_CAPABILITY(mu) { return 0; }
+
+ void doSomething() REQUIRES(mu);
+ };
+
+ void doSomethingTwice(MyClass& c) REQUIRES(c.getMu()) {
+ // The analysis thinks that c.getMu() == c.mu
+ c.doSomething();
+ c.doSomething();
+ }
+
+In the above example, ``doSomethingTwice()`` is an external routine that
+requires ``c.mu`` to be locked, which cannot be declared directly because ``mu``
+is private. This pattern is discouraged because it
+violates encapsulation, but it is sometimes necessary, especially when adding
+annotations to an existing code base. The workaround is to define ``getMu()``
+as a fake getter method, which is provided only for the benefit of thread
+safety analysis.
+
+
+.. _conditional_locks:
+
+No conditionally held locks.
+----------------------------
+
+The analysis must be able to determine whether a lock is held, or not held, at
+every program point. Thus, sections of code where a lock *might be held* will
+generate spurious warnings (false positives). For example:
+
+.. code-block:: c++
+
+ void foo() {
+ bool b = needsToLock();
+ if (b) mu.Lock();
+ ... // Warning! Mutex 'mu' is not held on every path through here.
+ if (b) mu.Unlock();
+ }
+
+
+No checking inside constructors and destructors.
+------------------------------------------------
+
+The analysis currently does not do any checking inside constructors or
+destructors. In other words, every constructor and destructor is treated as
+if it was annotated with ``NO_THREAD_SAFETY_ANALYSIS``.
+The reason for this is that during initialization, only one thread typically
+has access to the object which is being initialized, and it is thus safe (and
+common practice) to initialize guarded members without acquiring any locks.
+The same is true of destructors.
+
+Ideally, the analysis would allow initialization of guarded members inside the
+object being initialized or destroyed, while still enforcing the usual access
+restrictions on everything else. However, this is difficult to enforce in
+practice, because in complex pointer-based data structures, it is hard to
+determine what data is owned by the enclosing object.
+
+No inlining.
+------------
+
+Thread safety analysis is strictly intra-procedural, just like ordinary type
+checking. It relies only on the declared attributes of a function, and will
+not attempt to inline any method calls. As a result, code such as the
+following will not work:
+
+.. code-block:: c++
+
+ template<class T>
+ class AutoCleanup {
+ T* object;
+ void (T::*mp)();
+
+ public:
+ AutoCleanup(T* obj, void (T::*imp)()) : object(obj), mp(imp) { }
+ ~AutoCleanup() { (object->*mp)(); }
+ };
+
+ Mutex mu;
+ void foo() {
+ mu.Lock();
+ AutoCleanup<Mutex>(&mu, &Mutex::Unlock);
+ // ...
+ } // Warning, mu is not unlocked.
+
+In this case, the destructor of ``Autocleanup`` calls ``mu.Unlock()``, so
+the warning is bogus. However,
+thread safety analysis cannot see the unlock, because it does not attempt to
+inline the destructor. Moreover, there is no way to annotate the destructor,
+because the destructor is calling a function that is not statically known.
+This pattern is simply not supported.
+
+
+No alias analysis.
+------------------
+
+The analysis currently does not track pointer aliases. Thus, there can be
+false positives if two pointers both point to the same mutex.
+
+
+.. code-block:: c++
+
+ class MutexUnlocker {
+ Mutex* mu;
+
+ public:
+ MutexUnlocker(Mutex* m) RELEASE(m) : mu(m) { mu->Unlock(); }
+ ~MutexUnlocker() ACQUIRE(mu) { mu->Lock(); }
+ };
+
+ Mutex mutex;
+ void test() REQUIRES(mutex) {
+ {
+ MutexUnlocker munl(&mutex); // unlocks mutex
+ doSomeIO();
+ } // Warning: locks munl.mu
+ }
+
+The MutexUnlocker class is intended to be the dual of the MutexLocker class,
+defined in :ref:`mutexheader`. However, it doesn't work because the analysis
+doesn't know that munl.mu == mutex. The SCOPED_CAPABILITY attribute handles
+aliasing for MutexLocker, but does so only for that particular pattern.
+
+
+ACQUIRED_BEFORE(...) and ACQUIRED_AFTER(...) are currently unimplemented.
+-------------------------------------------------------------------------
+
+To be fixed in a future update.
+
+
+.. _mutexheader:
+
+mutex.h
+=======
+
+Thread safety analysis can be used with any threading library, but it does
+require that the threading API be wrapped in classes and methods which have the
+appropriate annotations. The following code provides ``mutex.h`` as an example;
+these methods should be filled in to call the appropriate underlying
+implementation.
+
+
+.. code-block:: c++
+
+
+ #ifndef THREAD_SAFETY_ANALYSIS_MUTEX_H
+ #define THREAD_SAFETY_ANALYSIS_MUTEX_H
+
+ // Enable thread safety attributes only with clang.
+ // The attributes can be safely erased when compiling with other compilers.
+ #if defined(__clang__) && (!defined(SWIG))
+ #define THREAD_ANNOTATION_ATTRIBUTE__(x) __attribute__((x))
+ #else
+ #define THREAD_ANNOTATION_ATTRIBUTE__(x) // no-op
+ #endif
+
+ #define CAPABILITY(x) \
+ THREAD_ANNOTATION_ATTRIBUTE__(capability(x))
+
+ #define SCOPED_CAPABILITY \
+ THREAD_ANNOTATION_ATTRIBUTE__(scoped_lockable)
+
+ #define GUARDED_BY(x) \
+ THREAD_ANNOTATION_ATTRIBUTE__(guarded_by(x))
+
+ #define PT_GUARDED_BY(x) \
+ THREAD_ANNOTATION_ATTRIBUTE__(pt_guarded_by(x))
+
+ #define ACQUIRED_BEFORE(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(acquired_before(__VA_ARGS__))
+
+ #define ACQUIRED_AFTER(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(acquired_after(__VA_ARGS__))
+
+ #define REQUIRES(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(requires_capability(__VA_ARGS__))
+
+ #define REQUIRES_SHARED(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(requires_shared_capability(__VA_ARGS__))
+
+ #define ACQUIRE(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(acquire_capability(__VA_ARGS__))
+
+ #define ACQUIRE_SHARED(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(acquire_shared_capability(__VA_ARGS__))
+
+ #define RELEASE(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(release_capability(__VA_ARGS__))
+
+ #define RELEASE_SHARED(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(release_shared_capability(__VA_ARGS__))
+
+ #define TRY_ACQUIRE(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(try_acquire_capability(__VA_ARGS__))
+
+ #define TRY_ACQUIRE_SHARED(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(try_acquire_shared_capability(__VA_ARGS__))
+
+ #define EXCLUDES(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(locks_excluded(__VA_ARGS__))
+
+ #define ASSERT_CAPABILITY(x) \
+ THREAD_ANNOTATION_ATTRIBUTE__(assert_capability(x))
+
+ #define ASSERT_SHARED_CAPABILITY(x) \
+ THREAD_ANNOTATION_ATTRIBUTE__(assert_shared_capability(x))
+
+ #define RETURN_CAPABILITY(x) \
+ THREAD_ANNOTATION_ATTRIBUTE__(lock_returned(x))
+
+ #define NO_THREAD_SAFETY_ANALYSIS \
+ THREAD_ANNOTATION_ATTRIBUTE__(no_thread_safety_analysis)
+
+
+ // Defines an annotated interface for mutexes.
+ // These methods can be implemented to use any internal mutex implementation.
+ class CAPABILITY("mutex") Mutex {
+ public:
+ // Acquire/lock this mutex exclusively. Only one thread can have exclusive
+ // access at any one time. Write operations to guarded data require an
+ // exclusive lock.
+ void Lock() ACQUIRE();
+
+ // Acquire/lock this mutex for read operations, which require only a shared
+ // lock. This assumes a multiple-reader, single writer semantics. Multiple
+ // threads may acquire the mutex simultaneously as readers, but a writer
+ // must wait for all of them to release the mutex before it can acquire it
+ // exclusively.
+ void ReaderLock() ACQUIRE_SHARED();
+
+ // Release/unlock an exclusive mutex.
+ void Unlock() RELEASE();
+
+ // Release/unlock a shared mutex.
+ void ReaderUnlock() RELEASE_SHARED();
+
+ // Try to acquire the mutex. Returns true on success, and false on failure.
+ bool TryLock() TRY_ACQUIRE(true);
+
+ // Try to acquire the mutex for read operations.
+ bool ReaderTryLock() TRY_ACQUIRE_SHARED(true);
+
+ // Assert that this mutex is currently held by the calling thread.
+ void AssertHeld() ASSERT_CAPABILITY(this);
+
+ // Assert that is mutex is currently held for read operations.
+ void AssertReaderHeld() ASSERT_SHARED_CAPABILITY(this);
+
+ // For negative capabilities.
+ const Mutex& operator!() const { return *this; }
+ };
+
+
+ // MutexLocker is an RAII class that acquires a mutex in its constructor, and
+ // releases it in its destructor.
+ class SCOPED_CAPABILITY MutexLocker {
+ private:
+ Mutex* mut;
+
+ public:
+ MutexLocker(Mutex *mu) ACQUIRE(mu) : mut(mu) {
+ mu->Lock();
+ }
+ ~MutexLocker() RELEASE() {
+ mut->Unlock();
+ }
+ };
+
+
+ #ifdef USE_LOCK_STYLE_THREAD_SAFETY_ATTRIBUTES
+ // The original version of thread safety analysis the following attribute
+ // definitions. These use a lock-based terminology. They are still in use
+ // by existing thread safety code, and will continue to be supported.
+
+ // Deprecated.
+ #define PT_GUARDED_VAR \
+ THREAD_ANNOTATION_ATTRIBUTE__(pt_guarded_var)
+
+ // Deprecated.
+ #define GUARDED_VAR \
+ THREAD_ANNOTATION_ATTRIBUTE__(guarded_var)
+
+ // Replaced by REQUIRES
+ #define EXCLUSIVE_LOCKS_REQUIRED(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(exclusive_locks_required(__VA_ARGS__))
+
+ // Replaced by REQUIRES_SHARED
+ #define SHARED_LOCKS_REQUIRED(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(shared_locks_required(__VA_ARGS__))
+
+ // Replaced by CAPABILITY
+ #define LOCKABLE \
+ THREAD_ANNOTATION_ATTRIBUTE__(lockable)
+
+ // Replaced by SCOPED_CAPABILITY
+ #define SCOPED_LOCKABLE \
+ THREAD_ANNOTATION_ATTRIBUTE__(scoped_lockable)
+
+ // Replaced by ACQUIRE
+ #define EXCLUSIVE_LOCK_FUNCTION(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(exclusive_lock_function(__VA_ARGS__))
+
+ // Replaced by ACQUIRE_SHARED
+ #define SHARED_LOCK_FUNCTION(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(shared_lock_function(__VA_ARGS__))
+
+ // Replaced by RELEASE and RELEASE_SHARED
+ #define UNLOCK_FUNCTION(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(unlock_function(__VA_ARGS__))
+
+ // Replaced by TRY_ACQUIRE
+ #define EXCLUSIVE_TRYLOCK_FUNCTION(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(exclusive_trylock_function(__VA_ARGS__))
+
+ // Replaced by TRY_ACQUIRE_SHARED
+ #define SHARED_TRYLOCK_FUNCTION(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(shared_trylock_function(__VA_ARGS__))
+
+ // Replaced by ASSERT_CAPABILITY
+ #define ASSERT_EXCLUSIVE_LOCK(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(assert_exclusive_lock(__VA_ARGS__))
+
+ // Replaced by ASSERT_SHARED_CAPABILITY
+ #define ASSERT_SHARED_LOCK(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(assert_shared_lock(__VA_ARGS__))
+
+ // Replaced by EXCLUDE_CAPABILITY.
+ #define LOCKS_EXCLUDED(...) \
+ THREAD_ANNOTATION_ATTRIBUTE__(locks_excluded(__VA_ARGS__))
+
+ // Replaced by RETURN_CAPABILITY
+ #define LOCK_RETURNED(x) \
+ THREAD_ANNOTATION_ATTRIBUTE__(lock_returned(x))
+
+ #endif // USE_LOCK_STYLE_THREAD_SAFETY_ATTRIBUTES
+
+ #endif // THREAD_SAFETY_ANALYSIS_MUTEX_H
+
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThreadSanitizer.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThreadSanitizer.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThreadSanitizer.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/ThreadSanitizer.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,134 @@
+ThreadSanitizer
+===============
+
+Introduction
+------------
+
+ThreadSanitizer is a tool that detects data races. It consists of a compiler
+instrumentation module and a run-time library. Typical slowdown introduced by
+ThreadSanitizer is about **5x-15x**. Typical memory overhead introduced by
+ThreadSanitizer is about **5x-10x**.
+
+How to build
+------------
+
+Build LLVM/Clang with `CMake <http://llvm.org/docs/CMake.html>`_.
+
+Supported Platforms
+-------------------
+
+ThreadSanitizer is supported on Linux x86_64 (tested on Ubuntu 12.04).
+Support for other 64-bit architectures is possible, contributions are welcome.
+Support for 32-bit platforms is problematic and is not planned.
+
+Usage
+-----
+
+Simply compile and link your program with ``-fsanitize=thread``. To get a
+reasonable performance add ``-O1`` or higher. Use ``-g`` to get file names
+and line numbers in the warning messages.
+
+Example:
+
+.. code-block:: console
+
+ % cat projects/compiler-rt/lib/tsan/lit_tests/tiny_race.c
+ #include <pthread.h>
+ int Global;
+ void *Thread1(void *x) {
+ Global = 42;
+ return x;
+ }
+ int main() {
+ pthread_t t;
+ pthread_create(&t, NULL, Thread1, NULL);
+ Global = 43;
+ pthread_join(t, NULL);
+ return Global;
+ }
+
+ $ clang -fsanitize=thread -g -O1 tiny_race.c
+
+If a bug is detected, the program will print an error message to stderr.
+Currently, ThreadSanitizer symbolizes its output using an external
+``addr2line`` process (this will be fixed in future).
+
+.. code-block:: bash
+
+ % ./a.out
+ WARNING: ThreadSanitizer: data race (pid=19219)
+ Write of size 4 at 0x7fcf47b21bc0 by thread T1:
+ #0 Thread1 tiny_race.c:4 (exe+0x00000000a360)
+
+ Previous write of size 4 at 0x7fcf47b21bc0 by main thread:
+ #0 main tiny_race.c:10 (exe+0x00000000a3b4)
+
+ Thread T1 (running) created at:
+ #0 pthread_create tsan_interceptors.cc:705 (exe+0x00000000c790)
+ #1 main tiny_race.c:9 (exe+0x00000000a3a4)
+
+``__has_feature(thread_sanitizer)``
+------------------------------------
+
+In some cases one may need to execute different code depending on whether
+ThreadSanitizer is enabled.
+:ref:`\_\_has\_feature <langext-__has_feature-__has_extension>` can be used for
+this purpose.
+
+.. code-block:: c
+
+ #if defined(__has_feature)
+ # if __has_feature(thread_sanitizer)
+ // code that builds only under ThreadSanitizer
+ # endif
+ #endif
+
+``__attribute__((no_sanitize("thread")))``
+-----------------------------------------------
+
+Some code should not be instrumented by ThreadSanitizer. One may use the
+function attribute ``no_sanitize("thread")`` to disable instrumentation of plain
+(non-atomic) loads/stores in a particular function. ThreadSanitizer still
+instruments such functions to avoid false positives and provide meaningful stack
+traces. This attribute may not be supported by other compilers, so we suggest
+to use it together with ``__has_feature(thread_sanitizer)``.
+
+Blacklist
+---------
+
+ThreadSanitizer supports ``src`` and ``fun`` entity types in
+:doc:`SanitizerSpecialCaseList`, that can be used to suppress data race reports
+in the specified source files or functions. Unlike functions marked with
+``no_sanitize("thread")`` attribute, blacklisted functions are not instrumented
+at all. This can lead to false positives due to missed synchronization via
+atomic operations and missed stack frames in reports.
+
+Limitations
+-----------
+
+* ThreadSanitizer uses more real memory than a native run. At the default
+ settings the memory overhead is 5x plus 1Mb per each thread. Settings with 3x
+ (less accurate analysis) and 9x (more accurate analysis) overhead are also
+ available.
+* ThreadSanitizer maps (but does not reserve) a lot of virtual address space.
+ This means that tools like ``ulimit`` may not work as usually expected.
+* Libc/libstdc++ static linking is not supported.
+* Non-position-independent executables are not supported. Therefore, the
+ ``fsanitize=thread`` flag will cause Clang to act as though the ``-fPIE``
+ flag had been supplied if compiling without ``-fPIC``, and as though the
+ ``-pie`` flag had been supplied if linking an executable.
+
+Current Status
+--------------
+
+ThreadSanitizer is in beta stage. It is known to work on large C++ programs
+using pthreads, but we do not promise anything (yet). C++11 threading is
+supported with llvm libc++. The test suite is integrated into CMake build
+and can be run with ``make check-tsan`` command.
+
+We are actively working on enhancing the tool --- stay tuned. Any help,
+especially in the form of minimized standalone tests is more than welcome.
+
+More Information
+----------------
+`<https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual>`_
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/Toolchain.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/Toolchain.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/Toolchain.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/Toolchain.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,354 @@
+===============================
+Assembling a Complete Toolchain
+===============================
+
+.. contents::
+ :local:
+ :depth: 2
+
+Introduction
+============
+
+Clang is only one component in a complete tool chain for C family
+programming languages. In order to assemble a complete toolchain,
+additional tools and runtime libraries are required. Clang is designed
+to interoperate with existing tools and libraries for its target
+platforms, and the LLVM project provides alternatives for a number
+of these components.
+
+This document describes the required and optional components in a
+complete toolchain, where to find them, and the supported versions
+and limitations of each option.
+
+.. warning::
+
+ This document currently describes Clang configurations on POSIX-like
+ operating systems with the GCC-compatible ``clang`` driver. When
+ targeting Windows with the MSVC-compatible ``clang-cl`` driver, some
+ of the details are different.
+
+Tools
+=====
+
+.. FIXME: Describe DWARF-related tools
+
+A complete compilation of C family programming languages typically
+involves the following pipeline of tools, some of which are omitted
+in some compilations:
+
+* **Preprocessor**: This performs the actions of the C preprocessor:
+ expanding #includes and #defines.
+ The ``-E`` flag instructs Clang to stop after this step.
+
+* **Parsing**: This parses and semantically analyzes the source language and
+ builds a source-level intermediate representation ("AST"), producing a
+ :ref:`precompiled header (PCH) <usersmanual-precompiled-headers>`,
+ preamble, or
+ :doc:`precompiled module file (PCM) <Modules>`,
+ depending on the input.
+ The ``-precompile`` flag instructs Clang to stop after this step. This is
+ the default when the input is a header file.
+
+* **IR generation**: This converts the source-level intermediate representation
+ into an optimizer-specific intermediate representation (IR); for Clang, this
+ is LLVM IR.
+ The ``-emit-llvm`` flag instructs Clang to stop after this step. If combined
+ with ``-S``, Clang will produce textual LLVM IR; otherwise, it will produce
+ LLVM IR bitcode.
+
+* **Compiler backend**: This converts the intermediate representation
+ into target-specific assembly code.
+ The ``-S`` flag instructs Clang to stop after this step.
+
+* **Assembler**: This converts target-specific assembly code into
+ target-specific machine code object files.
+ The ``-c`` flag instructs Clang to stop after this step.
+
+* **Linker**: This combines multiple object files into a single image
+ (either a shared object or an executable).
+
+Clang provides all of these pieces other than the linker. When multiple
+steps are performed by the same tool, it is common for the steps to be
+fused together to avoid creating intermediate files.
+
+When given an output of one of the above steps as an input, earlier steps
+are skipped (for instance, a ``.s`` file input will be assembled and linked).
+
+The Clang driver can be invoked with the ``-###`` flag (this argument will need
+to be escaped under most shells) to see which commands it would run for the
+above steps, without running them. The ``-v`` (verbose) flag will print the
+commands in addition to running them.
+
+Clang frontend
+--------------
+
+The Clang frontend (``clang -cc1``) is used to compile C family languages. The
+command-line interface of the frontend is considered to be an implementation
+detail, intentionally has no external documentation, and is subject to change
+without notice.
+
+Language frontends for other languages
+--------------------------------------
+
+Clang can be provided with inputs written in non-C-family languages. In such
+cases, an external tool will be used to compile the input. The
+currently-supported languages are:
+
+* Ada (``-x ada``, ``.ad[bs]``)
+* Fortran (``-x f95``, ``.f``, ``.f9[05]``, ``.for``, ``.fpp``, case-insensitive)
+* Java (``-x java``)
+
+In each case, GCC will be invoked to compile the input.
+
+Assember
+--------
+
+Clang can either use LLVM's integrated assembler or an external system-specific
+tool (for instance, the GNU Assembler on GNU OSes) to produce machine code from
+assembly.
+By default, Clang uses LLVM's integrataed assembler on all targets where it is
+supported. If you wish to use the system assember instead, use the
+``-fno-integrated-as`` option.
+
+Linker
+------
+
+Clang can be configured to use one of several different linkers:
+
+* GNU ld
+* GNU gold
+* LLVM's `lld <http://lld.llvm.org>`_
+* MSVC's link.exe
+
+Link-time optimization is natively supported by lld, and supported via
+a `linker plugin <http://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.
+
+Runtime libraries
+=================
+
+A number of different runtime libraries are required to provide different
+layers of support for C family programs. Clang will implicitly link an
+appropriate implementation of each runtime library, selected based on
+target defaults or explicitly selected by the ``--rtlib=`` and ``--stdlib=``
+flags.
+
+The set of implicitly-linked libraries depend on the language mode. As a
+consequence, you should use ``clang++`` when linking C++ programs in order
+to ensure the C++ runtimes are provided.
+
+.. note::
+
+ There may exist other implementations for these components not described
+ below. Please let us know how well those other implementations work with
+ Clang so they can be added to this list!
+
+.. FIXME: Describe Objective-C runtime libraries
+.. FIXME: Describe profiling runtime library
+.. FIXME: Describe cuda/openmp/opencl/... runtime libraries
+
+Compiler runtime
+----------------
+
+The compiler runtime library provides definitions of functions implicitly
+invoked by the compiler to support operations not natively supported by
+the underlying hardware (for instance, 128-bit integer multiplications),
+and where inline expansion of the operation is deemed unsuitable.
+
+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
+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``
+and/or ``-DLIBCXXABI_USE_COMPILER_RT=YES`` to ``cmake``. Otherwise, you
+may end up with both runtime libraries linked into your program (this is
+typically harmless, but wasteful).
+
+libgcc_s (GNU)
+^^^^^^^^^^^^^^
+
+`GCC's runtime library <https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html>`_
+can be used in place of compiler-rt. However, it lacks several functions
+that LLVM may emit references to, particularly when using Clang's
+``__builtin_*_overflow`` family of intrinsics.
+
+You can instruct Clang to use libgcc_s with the ``--rtlib=libgcc`` flag.
+This is not supported on every platform.
+
+Atomics library
+---------------
+
+If your program makes use of atomic operations and the compiler is not able
+to lower them all directly to machine instructions (because there either is
+no known suitable machine instruction or the operand is not known to be
+suitably aligned), a call to a runtime library ``__atomic_*`` function
+will be generated. A runtime library containing these atomics functions is
+necessary for such programs.
+
+compiler-rt (LLVM)
+^^^^^^^^^^^^^^^^^^
+
+compiler-rt contains an implementation of an atomics library.
+
+libatomic (GNU)
+^^^^^^^^^^^^^^^
+
+libgcc_s does not provide an implementation of an atomics library. Instead,
+`GCC's libatomic library <https://gcc.gnu.org/wiki/Atomic/GCCMM>`_ can be
+used to supply these when using libgcc_s.
+
+.. note::
+
+ Clang does not currently automatically link against libatomic when using
+ libgcc_s. You may need to manually add ``-latomic`` to support this
+ 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://mentorembedded.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 http://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.
+
+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)
+^^^^^^^^^^^^^^
+
+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>`_.
+
+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>`_
+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://mentorembedded.github.io/cxx-abi/abi.html>`_ and
+`Level II of the exception handling support
+<http://mentorembedded.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
+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++.
+
+.. note::
+
+ Clang does not currently automatically link against libatomic when statically
+ linking libstdc++. You may need to manually add ``-lsupc++`` to support this
+ configuration when using ``-static`` or ``-static-libstdc++``.
+
+libcxxrt (PathScale)
+^^^^^^^^^^^^^^^^^^^^
+
+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>`_.
+
+libc++ (LLVM)
+^^^^^^^^^^^^^
+
+`libc++ <http://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.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/Tooling.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/Tooling.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/Tooling.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/Tooling.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,97 @@
+=================================================
+Choosing the Right Interface for Your Application
+=================================================
+
+Clang provides infrastructure to write tools that need syntactic and semantic
+information about a program. This document will give a short introduction of
+the different ways to write clang tools, and their pros and cons.
+
+LibClang
+--------
+
+`LibClang <http://clang.llvm.org/doxygen/group__CINDEX.html>`_ is a stable high
+level C interface to clang. When in doubt LibClang is probably the interface
+you want to use. Consider the other interfaces only when you have a good
+reason not to use LibClang.
+
+Canonical examples of when to use LibClang:
+
+* Xcode
+* Clang Python Bindings
+
+Use LibClang when you...:
+
+* want to interface with clang from other languages than C++
+* need a stable interface that takes care to be backwards compatible
+* want powerful high-level abstractions, like iterating through an AST with a
+ cursor, and don't want to learn all the nitty gritty details of Clang's AST.
+
+Do not use LibClang when you...:
+
+* want full control over the Clang AST
+
+Clang Plugins
+-------------
+
+:doc:`Clang Plugins <ClangPlugins>` allow you to run additional actions on the
+AST as part of a compilation. Plugins are dynamic libraries that are loaded at
+runtime by the compiler, and they're easy to integrate into your build
+environment.
+
+Canonical examples of when to use Clang Plugins:
+
+* special lint-style warnings or errors for your project
+* creating additional build artifacts from a single compile step
+
+Use Clang Plugins when you...:
+
+* need your tool to rerun if any of the dependencies change
+* want your tool to make or break a build
+* need full control over the Clang AST
+
+Do not use Clang Plugins when you...:
+
+* want to run tools outside of your build environment
+* want full control on how Clang is set up, including mapping of in-memory
+ virtual files
+* need to run over a specific subset of files in your project which is not
+ necessarily related to any changes which would trigger rebuilds
+
+LibTooling
+----------
+
+:doc:`LibTooling <LibTooling>` is a C++ interface aimed at writing standalone
+tools, as well as integrating into services that run clang tools. Canonical
+examples of when to use LibTooling:
+
+* a simple syntax checker
+* refactoring tools
+
+Use LibTooling when you...:
+
+* want to run tools over a single file, or a specific subset of files,
+ independently of the build system
+* want full control over the Clang AST
+* want to share code with Clang Plugins
+
+Do not use LibTooling when you...:
+
+* want to run as part of the build triggered by dependency changes
+* want a stable interface so you don't need to change your code when the AST API
+ changes
+* want high level abstractions like cursors and code completion out of the box
+* do not want to write your tools in C++
+
+:doc:`Clang tools <ClangTools>` are a collection of specific developer tools
+built on top of the LibTooling infrastructure as part of the Clang project.
+They are targeted at automating and improving core development activities of
+C/C++ developers.
+
+Examples of tools we are building or planning as part of the Clang project:
+
+* Syntax checking (:program:`clang-check`)
+* Automatic fixing of compile errors (:program:`clang-fixit`)
+* Automatic code formatting (:program:`clang-format`)
+* Migration tools for new features in new language standards
+* Core refactoring tools
+
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/UndefinedBehaviorSanitizer.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/UndefinedBehaviorSanitizer.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/UndefinedBehaviorSanitizer.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/UndefinedBehaviorSanitizer.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,279 @@
+==========================
+UndefinedBehaviorSanitizer
+==========================
+
+.. contents::
+ :local:
+
+Introduction
+============
+
+UndefinedBehaviorSanitizer (UBSan) is a fast undefined behavior detector.
+UBSan modifies the program at compile-time to catch various kinds of undefined
+behavior during program execution, for example:
+
+* Using misaligned or null pointer
+* Signed integer overflow
+* Conversion to, from, or between floating-point types which would
+ overflow the destination
+
+See the full list of available :ref:`checks <ubsan-checks>` below.
+
+UBSan has an optional run-time library which provides better error reporting.
+The checks have small runtime cost and no impact on address space layout or ABI.
+
+How to build
+============
+
+Build LLVM/Clang with `CMake <http://llvm.org/docs/CMake.html>`_.
+
+Usage
+=====
+
+Use ``clang++`` to compile and link your program with ``-fsanitize=undefined``
+flag. Make sure to use ``clang++`` (not ``ld``) as a linker, so that your
+executable is linked with proper UBSan runtime libraries. You can use ``clang``
+instead of ``clang++`` if you're compiling/linking C code.
+
+.. code-block:: console
+
+ % cat test.cc
+ int main(int argc, char **argv) {
+ int k = 0x7fffffff;
+ k += argc;
+ return 0;
+ }
+ % clang++ -fsanitize=undefined test.cc
+ % ./a.out
+ test.cc:3:5: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
+
+You can enable only a subset of :ref:`checks <ubsan-checks>` offered by UBSan,
+and define the desired behavior for each kind of check:
+
+* ``-fsanitize=...``: print a verbose error report and continue execution (default);
+* ``-fno-sanitize-recover=...``: print a verbose error report and exit the program;
+* ``-fsanitize-trap=...``: execute a trap instruction (doesn't require UBSan run-time support).
+
+For example if you compile/link your program as:
+
+.. code-block:: console
+
+ % clang++ -fsanitize=signed-integer-overflow,null,alignment -fno-sanitize-recover=null -fsanitize-trap=alignment
+
+the program will continue execution after signed integer overflows, exit after
+the first invalid use of a null pointer, and trap after the first use of misaligned
+pointer.
+
+.. _ubsan-checks:
+
+Available checks
+================
+
+Available checks are:
+
+ - ``-fsanitize=alignment``: Use of a misaligned pointer or creation
+ of a misaligned reference.
+ - ``-fsanitize=bool``: Load of a ``bool`` value which is neither
+ ``true`` nor ``false``.
+ - ``-fsanitize=bounds``: Out of bounds array indexing, in cases
+ where the array bound can be statically determined.
+ - ``-fsanitize=enum``: Load of a value of an enumerated type which
+ is not in the range of representable values for that enumerated
+ type.
+ - ``-fsanitize=float-cast-overflow``: Conversion to, from, or
+ between floating-point types which would overflow the
+ destination.
+ - ``-fsanitize=float-divide-by-zero``: Floating point division by
+ zero.
+ - ``-fsanitize=function``: Indirect call of a function through a
+ function pointer of the wrong type (Linux, C++ and x86/x86_64 only).
+ - ``-fsanitize=integer-divide-by-zero``: Integer division by zero.
+ - ``-fsanitize=nonnull-attribute``: Passing null pointer as a function
+ parameter which is declared to never be null.
+ - ``-fsanitize=null``: Use of a null pointer or creation of a null
+ reference.
+ - ``-fsanitize=nullability-arg``: Passing null as a function parameter
+ which is annotated with ``_Nonnull``.
+ - ``-fsanitize=nullability-assign``: Assigning null to an lvalue which
+ is annotated with ``_Nonnull``.
+ - ``-fsanitize=nullability-return``: Returning null from a function with
+ a return type annotated with ``_Nonnull``.
+ - ``-fsanitize=object-size``: An attempt to potentially use bytes which
+ the optimizer can determine are not part of the object being accessed.
+ This will also detect some types of undefined behavior that may not
+ directly access memory, but are provably incorrect given the size of
+ the objects involved, such as invalid downcasts and calling methods on
+ invalid pointers. These checks are made in terms of
+ ``__builtin_object_size``, and consequently may be able to detect more
+ problems at higher optimization levels.
+ - ``-fsanitize=pointer-overflow``: Performing pointer arithmetic which
+ overflows.
+ - ``-fsanitize=return``: In C++, reaching the end of a
+ value-returning function without returning a value.
+ - ``-fsanitize=returns-nonnull-attribute``: Returning null pointer
+ from a function which is declared to never return null.
+ - ``-fsanitize=shift``: Shift operators where the amount shifted is
+ greater or equal to the promoted bit-width of the left hand side
+ or less than zero, or where the left hand side is negative. For a
+ signed left shift, also checks for signed overflow in C, and for
+ unsigned overflow in C++. You can use ``-fsanitize=shift-base`` or
+ ``-fsanitize=shift-exponent`` to check only left-hand side or
+ right-hand side of shift operation, respectively.
+ - ``-fsanitize=signed-integer-overflow``: Signed integer overflow,
+ including all the checks added by ``-ftrapv``, and checking for
+ overflow in signed division (``INT_MIN / -1``).
+ - ``-fsanitize=unreachable``: If control flow reaches
+ ``__builtin_unreachable``.
+ - ``-fsanitize=unsigned-integer-overflow``: Unsigned integer
+ overflows. Note that unlike signed integer overflow, unsigned integer
+ is not undefined behavior. However, while it has well-defined semantics,
+ it is often unintentional, so UBSan offers to catch it.
+ - ``-fsanitize=vla-bound``: A variable-length array whose bound
+ does not evaluate to a positive value.
+ - ``-fsanitize=vptr``: Use of an object whose vptr indicates that
+ it is of the wrong dynamic type, or that its lifetime has not
+ begun or has ended. Incompatible with ``-fno-rtti``. Link must
+ be performed by ``clang++``, not ``clang``, to make sure C++-specific
+ parts of the runtime library and C++ standard libraries are present.
+
+You can also use the following check groups:
+ - ``-fsanitize=undefined``: All of the checks listed above other than
+ ``unsigned-integer-overflow`` and the ``nullability-*`` checks.
+ - ``-fsanitize=undefined-trap``: Deprecated alias of
+ ``-fsanitize=undefined``.
+ - ``-fsanitize=integer``: Checks for undefined or suspicious integer
+ behavior (e.g. unsigned integer overflow).
+ - ``-fsanitize=nullability``: Enables ``nullability-arg``,
+ ``nullability-assign``, and ``nullability-return``. While violating
+ nullability does not have undefined behavior, it is often unintentional,
+ so UBSan offers to catch it.
+
+Volatile
+--------
+
+The ``null``, ``alignment``, ``object-size``, and ``vptr`` checks do not apply
+to pointers to types with the ``volatile`` qualifier.
+
+Stack traces and report symbolization
+=====================================
+If you want UBSan to print symbolized stack trace for each error report, you
+will need to:
+
+#. Compile with ``-g`` and ``-fno-omit-frame-pointer`` to get proper debug
+ information in your binary.
+#. Run your program with environment variable
+ ``UBSAN_OPTIONS=print_stacktrace=1``.
+#. Make sure ``llvm-symbolizer`` binary is in ``PATH``.
+
+Issue Suppression
+=================
+
+UndefinedBehaviorSanitizer is not expected to produce false positives.
+If you see one, look again; most likely it is a true positive!
+
+Disabling Instrumentation with ``__attribute__((no_sanitize("undefined")))``
+----------------------------------------------------------------------------
+
+You disable UBSan checks for particular functions with
+``__attribute__((no_sanitize("undefined")))``. You can use all values of
+``-fsanitize=`` flag in this attribute, e.g. if your function deliberately
+contains possible signed integer overflow, you can use
+``__attribute__((no_sanitize("signed-integer-overflow")))``.
+
+This attribute may not be
+supported by other compilers, so consider using it together with
+``#if defined(__clang__)``.
+
+Suppressing Errors in Recompiled Code (Blacklist)
+-------------------------------------------------
+
+UndefinedBehaviorSanitizer supports ``src`` and ``fun`` entity types in
+:doc:`SanitizerSpecialCaseList`, that can be used to suppress error reports
+in the specified source files or functions.
+
+Runtime suppressions
+--------------------
+
+Sometimes you can suppress UBSan error reports for specific files, functions,
+or libraries without recompiling the code. You need to pass a path to
+suppression file in a ``UBSAN_OPTIONS`` environment variable.
+
+.. code-block:: bash
+
+ UBSAN_OPTIONS=suppressions=MyUBSan.supp
+
+You need to specify a :ref:`check <ubsan-checks>` you are suppressing and the
+bug location. For example:
+
+.. code-block:: bash
+
+ signed-integer-overflow:file-with-known-overflow.cpp
+ alignment:function_doing_unaligned_access
+ vptr:shared_object_with_vptr_failures.so
+
+There are several limitations:
+
+* Sometimes your binary must have enough debug info and/or symbol table, so
+ that the runtime could figure out source file or function name to match
+ against the suppression.
+* It is only possible to suppress recoverable checks. For the example above,
+ you can additionally pass
+ ``-fsanitize-recover=signed-integer-overflow,alignment,vptr``, although
+ most of UBSan checks are recoverable by default.
+* Check groups (like ``undefined``) can't be used in suppressions file, only
+ fine-grained checks are supported.
+
+Supported Platforms
+===================
+
+UndefinedBehaviorSanitizer is supported on the following OS:
+
+* Android
+* Linux
+* FreeBSD
+* OS X 10.6 onwards
+
+and for the following architectures:
+
+* i386/x86\_64
+* ARM
+* AArch64
+* PowerPC64
+* MIPS/MIPS64
+
+Current Status
+==============
+
+UndefinedBehaviorSanitizer is available on selected platforms starting from LLVM
+3.3. The test suite is integrated into the CMake build and can be run with
+``check-ubsan`` command.
+
+Additional Configuration
+========================
+
+UndefinedBehaviorSanitizer adds static check data for each check unless it is
+in trap mode. This check data includes the full file name. The option
+``-fsanitize-undefined-strip-path-components=N`` can be used to trim this
+information. If ``N`` is positive, file information emitted by
+UndefinedBehaviorSanitizer will drop the first ``N`` components from the file
+path. If ``N`` is negative, the last ``N`` components will be kept.
+
+Example
+-------
+
+For a file called ``/code/library/file.cpp``, here is what would be emitted:
+* Default (No flag, or ``-fsanitize-undefined-strip-path-components=0``): ``/code/library/file.cpp``
+* ``-fsanitize-undefined-strip-path-components=1``: ``code/library/file.cpp``
+* ``-fsanitize-undefined-strip-path-components=2``: ``library/file.cpp``
+* ``-fsanitize-undefined-strip-path-components=-1``: ``file.cpp``
+* ``-fsanitize-undefined-strip-path-components=-2``: ``library/file.cpp``
+
+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>`_
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/UsersManual.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/UsersManual.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/UsersManual.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/UsersManual.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,2840 @@
+============================
+Clang Compiler User's Manual
+============================
+
+.. include:: <isonum.txt>
+
+.. contents::
+ :local:
+
+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>`_.
+
+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 <http://clang-analyzer.llvm.org>`_, please see its web
+page.
+
+Clang is one component in a complete toolchain for C family languages.
+A separate document describes the other pieces necessary to
+:doc:`assemble a complete toolchain <Toolchain>`.
+
+Clang is designed to support the C family of programming languages,
+which includes :ref:`C <c>`, :ref:`Objective-C <objc>`, :ref:`C++ <cxx>`, and
+:ref:`Objective-C++ <objcxx>` as well as many dialects of those. For
+language-specific information, please see the corresponding language
+specific section:
+
+- :ref:`C Language <c>`: K&R C, ANSI C89, ISO C90, ISO C94 (C89+AMD1), ISO
+ C99 (+TC1, TC2, TC3).
+- :ref:`Objective-C Language <objc>`: ObjC 1, ObjC 2, ObjC 2.1, plus
+ variants depending on base language.
+- :ref:`C++ Language <cxx>`
+- :ref:`Objective C++ Language <objcxx>`
+- :ref:`OpenCL C Language <opencl>`: v1.0, v1.1, v1.2, v2.0.
+
+In addition to these base languages and their dialects, Clang supports a
+broad variety of language extensions, which are documented in the
+corresponding language section. These extensions are provided to be
+compatible with the GCC, Microsoft, and other popular compilers as well
+as to improve functionality through Clang-specific features. The Clang
+driver and language features are intentionally designed to be as
+compatible with the GNU GCC compiler as reasonably possible, easing
+migration from GCC to Clang. In most cases, code "just works".
+Clang also provides an alternative driver, :ref:`clang-cl`, that is designed
+to be compatible with the Visual C++ compiler, cl.exe.
+
+In addition to language specific features, Clang has a variety of
+features that depend on what CPU architecture or operating system is
+being compiled for. Please see the :ref:`Target-Specific Features and
+Limitations <target_features>` section for more details.
+
+The rest of the introduction introduces some basic :ref:`compiler
+terminology <terminology>` that is used throughout this manual and
+contains a basic :ref:`introduction to using Clang <basicusage>` as a
+command line compiler.
+
+.. _terminology:
+
+Terminology
+-----------
+
+Front end, parser, backend, preprocessor, undefined behavior,
+diagnostic, optimizer
+
+.. _basicusage:
+
+Basic Usage
+-----------
+
+Intro to how to use a C compiler for newbies.
+
+compile + link compile then link debug info enabling optimizations
+picking a language to use, defaults to C11 by default. Autosenses based
+on extension. using a makefile
+
+Command Line Options
+====================
+
+This section is generally an index into other sections. It does not go
+into depth on the ones that are covered by other sections. However, the
+first part introduces the language selection and other high level
+options like :option:`-c`, :option:`-g`, etc.
+
+Options to Control Error and Warning Messages
+---------------------------------------------
+
+.. option:: -Werror
+
+ Turn warnings into errors.
+
+.. This is in plain monospaced font because it generates the same label as
+.. -Werror, and Sphinx complains.
+
+``-Werror=foo``
+
+ Turn warning "foo" into an error.
+
+.. option:: -Wno-error=foo
+
+ Turn warning "foo" into an warning even if :option:`-Werror` is specified.
+
+.. option:: -Wfoo
+
+ Enable warning "foo".
+ See the :doc:`diagnostics reference <DiagnosticsReference>` for a complete
+ list of the warning flags that can be specified in this way.
+
+.. option:: -Wno-foo
+
+ Disable warning "foo".
+
+.. option:: -w
+
+ Disable all diagnostics.
+
+.. option:: -Weverything
+
+ :ref:`Enable all diagnostics. <diagnostics_enable_everything>`
+
+.. option:: -pedantic
+
+ Warn on language extensions.
+
+.. option:: -pedantic-errors
+
+ Error on language extensions.
+
+.. option:: -Wsystem-headers
+
+ Enable warnings from system headers.
+
+.. option:: -ferror-limit=123
+
+ Stop emitting diagnostics after 123 errors have been produced. The default is
+ 20, and the error limit can be disabled with `-ferror-limit=0`.
+
+.. option:: -ftemplate-backtrace-limit=123
+
+ Only emit up to 123 template instantiation notes within the template
+ instantiation backtrace for a single warning or error. The default is 10, and
+ the limit can be disabled with `-ftemplate-backtrace-limit=0`.
+
+.. _cl_diag_formatting:
+
+Formatting of Diagnostics
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Clang aims to produce beautiful diagnostics by default, particularly for
+new users that first come to Clang. However, different people have
+different preferences, and sometimes Clang is driven not by a human,
+but by a program that wants consistent and easily parsable output. For
+these cases, Clang provides a wide range of options to control the exact
+output format of the diagnostics that it generates.
+
+.. _opt_fshow-column:
+
+**-f[no-]show-column**
+ Print column number in diagnostic.
+
+ This option, which defaults to on, controls whether or not Clang
+ prints the column number of a diagnostic. For example, when this is
+ enabled, Clang will print something like:
+
+ ::
+
+ test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+ #endif bad
+ ^
+ //
+
+ When this is disabled, Clang will print "test.c:28: warning..." with
+ no column number.
+
+ The printed column numbers count bytes from the beginning of the
+ line; take care if your source contains multibyte characters.
+
+.. _opt_fshow-source-location:
+
+**-f[no-]show-source-location**
+ Print source file/line/column information in diagnostic.
+
+ This option, which defaults to on, controls whether or not Clang
+ prints the filename, line number and column number of a diagnostic.
+ For example, when this is enabled, Clang will print something like:
+
+ ::
+
+ test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+ #endif bad
+ ^
+ //
+
+ When this is disabled, Clang will not print the "test.c:28:8: "
+ part.
+
+.. _opt_fcaret-diagnostics:
+
+**-f[no-]caret-diagnostics**
+ Print source line and ranges from source code in diagnostic.
+ This option, which defaults to on, controls whether or not Clang
+ prints the source line, source ranges, and caret when emitting a
+ diagnostic. For example, when this is enabled, Clang will print
+ something like:
+
+ ::
+
+ test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+ #endif bad
+ ^
+ //
+
+**-f[no-]color-diagnostics**
+ This option, which defaults to on when a color-capable terminal is
+ detected, controls whether or not Clang prints diagnostics in color.
+
+ When this option is enabled, Clang will use colors to highlight
+ specific parts of the diagnostic, e.g.,
+
+ .. nasty hack to not lose our dignity
+
+ .. raw:: html
+
+ <pre>
+ <b><span style="color:black">test.c:28:8: <span style="color:magenta">warning</span>: extra tokens at end of #endif directive [-Wextra-tokens]</span></b>
+ #endif bad
+ <span style="color:green">^</span>
+ <span style="color:green">//</span>
+ </pre>
+
+ When this is disabled, Clang will just print:
+
+ ::
+
+ test.c:2:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+ #endif bad
+ ^
+ //
+
+**-fansi-escape-codes**
+ Controls whether ANSI escape codes are used instead of the Windows Console
+ API to output colored diagnostics. This option is only used on Windows and
+ defaults to off.
+
+.. option:: -fdiagnostics-format=clang/msvc/vi
+
+ Changes diagnostic output format to better match IDEs and command line tools.
+
+ This option controls the output format of the filename, line number,
+ and column printed in diagnostic messages. The options, and their
+ affect on formatting a simple conversion diagnostic, follow:
+
+ **clang** (default)
+ ::
+
+ t.c:3:11: warning: conversion specifies type 'char *' but the argument has type 'int'
+
+ **msvc**
+ ::
+
+ t.c(3,11) : warning: conversion specifies type 'char *' but the argument has type 'int'
+
+ **vi**
+ ::
+
+ t.c +3:11: warning: conversion specifies type 'char *' but the argument has type 'int'
+
+.. _opt_fdiagnostics-show-option:
+
+**-f[no-]diagnostics-show-option**
+ Enable ``[-Woption]`` information in diagnostic line.
+
+ This option, which defaults to on, controls whether or not Clang
+ prints the associated :ref:`warning group <cl_diag_warning_groups>`
+ option name when outputting a warning diagnostic. For example, in
+ this output:
+
+ ::
+
+ test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+ #endif bad
+ ^
+ //
+
+ Passing **-fno-diagnostics-show-option** will prevent Clang from
+ printing the [:ref:`-Wextra-tokens <opt_Wextra-tokens>`] information in
+ the diagnostic. This information tells you the flag needed to enable
+ or disable the diagnostic, either from the command line or through
+ :ref:`#pragma GCC diagnostic <pragma_GCC_diagnostic>`.
+
+.. _opt_fdiagnostics-show-category:
+
+.. option:: -fdiagnostics-show-category=none/id/name
+
+ Enable printing category information in diagnostic line.
+
+ This option, which defaults to "none", controls whether or not Clang
+ prints the category associated with a diagnostic when emitting it.
+ Each diagnostic may or many not have an associated category, if it
+ has one, it is listed in the diagnostic categorization field of the
+ diagnostic line (in the []'s).
+
+ For example, a format string warning will produce these three
+ renditions based on the setting of this option:
+
+ ::
+
+ t.c:3:11: warning: conversion specifies type 'char *' but the argument has type 'int' [-Wformat]
+ t.c:3:11: warning: conversion specifies type 'char *' but the argument has type 'int' [-Wformat,1]
+ t.c:3:11: warning: conversion specifies type 'char *' but the argument has type 'int' [-Wformat,Format String]
+
+ This category can be used by clients that want to group diagnostics
+ by category, so it should be a high level category. We want dozens
+ of these, not hundreds or thousands of them.
+
+.. _opt_fsave-optimization-record:
+
+**-fsave-optimization-record**
+ Write optimization remarks to a YAML file.
+
+ This option, which defaults to off, controls whether Clang writes
+ optimization reports to a YAML file. By recording diagnostics in a file,
+ using a structured YAML format, users can parse or sort the remarks in a
+ convenient way.
+
+.. _opt_foptimization-record-file:
+
+**-foptimization-record-file**
+ Control the file to which optimization reports are written.
+
+ When optimization reports are being output (see
+ :ref:`-fsave-optimization-record <opt_fsave-optimization-record>`), this
+ option controls the file to which those reports are written.
+
+ If this option is not used, optimization records are output to a file named
+ after the primary file being compiled. If that's "foo.c", for example,
+ optimization records are output to "foo.opt.yaml".
+
+.. _opt_fdiagnostics-show-hotness:
+
+**-f[no-]diagnostics-show-hotness**
+ Enable profile hotness information in diagnostic line.
+
+ This option controls whether Clang prints the profile hotness associated
+ with diagnostics in the presence of profile-guided optimization information.
+ This is currently supported with optimization remarks (see
+ :ref:`Options to Emit Optimization Reports <rpass>`). The hotness information
+ allows users to focus on the hot optimization remarks that are likely to be
+ more relevant for run-time performance.
+
+ For example, in this output, the block containing the callsite of `foo` was
+ executed 3000 times according to the profile data:
+
+ ::
+
+ s.c:7:10: remark: foo inlined into bar (hotness: 3000) [-Rpass-analysis=inline]
+ sum += foo(x, x - 2);
+ ^
+
+ This option is implied when
+ :ref:`-fsave-optimization-record <opt_fsave-optimization-record>` is used.
+ Otherwise, it defaults to off.
+
+.. _opt_fdiagnostics-hotness-threshold:
+
+**-fdiagnostics-hotness-threshold**
+ Prevent optimization remarks from being output if they do not have at least
+ this hotness value.
+
+ This option, which defaults to zero, controls the minimum hotness an
+ optimization remark would need in order to be output by Clang. This is
+ currently supported with optimization remarks (see :ref:`Options to Emit
+ Optimization Reports <rpass>`) when profile hotness information in
+ diagnostics is enabled (see
+ :ref:`-fdiagnostics-show-hotness <opt_fdiagnostics-show-hotness>`).
+
+.. _opt_fdiagnostics-fixit-info:
+
+**-f[no-]diagnostics-fixit-info**
+ Enable "FixIt" information in the diagnostics output.
+
+ This option, which defaults to on, controls whether or not Clang
+ prints the information on how to fix a specific diagnostic
+ underneath it when it knows. For example, in this output:
+
+ ::
+
+ test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+ #endif bad
+ ^
+ //
+
+ Passing **-fno-diagnostics-fixit-info** will prevent Clang from
+ printing the "//" line at the end of the message. This information
+ is useful for users who may not understand what is wrong, but can be
+ confusing for machine parsing.
+
+.. _opt_fdiagnostics-print-source-range-info:
+
+**-fdiagnostics-print-source-range-info**
+ Print machine parsable information about source ranges.
+ This option makes Clang print information about source ranges in a machine
+ parsable format after the file/line/column number information. The
+ information is a simple sequence of brace enclosed ranges, where each range
+ lists the start and end line/column locations. For example, in this output:
+
+ ::
+
+ exprs.c:47:15:{47:8-47:14}{47:17-47:24}: error: invalid operands to binary expression ('int *' and '_Complex float')
+ P = (P-42) + Gamma*4;
+ ~~~~~~ ^ ~~~~~~~
+
+ The {}'s are generated by -fdiagnostics-print-source-range-info.
+
+ The printed column numbers count bytes from the beginning of the
+ line; take care if your source contains multibyte characters.
+
+.. option:: -fdiagnostics-parseable-fixits
+
+ Print Fix-Its in a machine parseable form.
+
+ This option makes Clang print available Fix-Its in a machine
+ parseable format at the end of diagnostics. The following example
+ illustrates the format:
+
+ ::
+
+ fix-it:"t.cpp":{7:25-7:29}:"Gamma"
+
+ The range printed is a half-open range, so in this example the
+ characters at column 25 up to but not including column 29 on line 7
+ in t.cpp should be replaced with the string "Gamma". Either the
+ range or the replacement string may be empty (representing strict
+ insertions and strict erasures, respectively). Both the file name
+ and the insertion string escape backslash (as "\\\\"), tabs (as
+ "\\t"), newlines (as "\\n"), double quotes(as "\\"") and
+ non-printable characters (as octal "\\xxx").
+
+ The printed column numbers count bytes from the beginning of the
+ line; take care if your source contains multibyte characters.
+
+.. option:: -fno-elide-type
+
+ Turns off elision in template type printing.
+
+ The default for template type printing is to elide as many template
+ arguments as possible, removing those which are the same in both
+ template types, leaving only the differences. Adding this flag will
+ print all the template arguments. If supported by the terminal,
+ highlighting will still appear on differing arguments.
+
+ Default:
+
+ ::
+
+ t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<[...], map<float, [...]>>>' to 'vector<map<[...], map<double, [...]>>>' for 1st argument;
+
+ -fno-elide-type:
+
+ ::
+
+ t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<int, map<float, int>>>' to 'vector<map<int, map<double, int>>>' for 1st argument;
+
+.. option:: -fdiagnostics-show-template-tree
+
+ Template type diffing prints a text tree.
+
+ For diffing large templated types, this option will cause Clang to
+ display the templates as an indented text tree, one argument per
+ line, with differences marked inline. This is compatible with
+ -fno-elide-type.
+
+ Default:
+
+ ::
+
+ t.cc:4:5: note: candidate function not viable: no known conversion from 'vector<map<[...], map<float, [...]>>>' to 'vector<map<[...], map<double, [...]>>>' for 1st argument;
+
+ With :option:`-fdiagnostics-show-template-tree`:
+
+ ::
+
+ t.cc:4:5: note: candidate function not viable: no known conversion for 1st argument;
+ vector<
+ map<
+ [...],
+ map<
+ [float != double],
+ [...]>>>
+
+.. _cl_diag_warning_groups:
+
+Individual Warning Groups
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+TODO: Generate this from tblgen. Define one anchor per warning group.
+
+.. _opt_wextra-tokens:
+
+.. option:: -Wextra-tokens
+
+ Warn about excess tokens at the end of a preprocessor directive.
+
+ This option, which defaults to on, enables warnings about extra
+ tokens at the end of preprocessor directives. For example:
+
+ ::
+
+ test.c:28:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
+ #endif bad
+ ^
+
+ These extra tokens are not strictly conforming, and are usually best
+ handled by commenting them out.
+
+.. option:: -Wambiguous-member-template
+
+ Warn about unqualified uses of a member template whose name resolves to
+ another template at the location of the use.
+
+ This option, which defaults to on, enables a warning in the
+ following code:
+
+ ::
+
+ template<typename T> struct set{};
+ template<typename T> struct trait { typedef const T& type; };
+ struct Value {
+ template<typename T> void set(typename trait<T>::type value) {}
+ };
+ void foo() {
+ Value v;
+ v.set<double>(3.2);
+ }
+
+ C++ [basic.lookup.classref] requires this to be an error, but,
+ because it's hard to work around, Clang downgrades it to a warning
+ as an extension.
+
+.. option:: -Wbind-to-temporary-copy
+
+ Warn about an unusable copy constructor when binding a reference to a
+ temporary.
+
+ This option enables warnings about binding a
+ reference to a temporary when the temporary doesn't have a usable
+ copy constructor. For example:
+
+ ::
+
+ struct NonCopyable {
+ NonCopyable();
+ private:
+ NonCopyable(const NonCopyable&);
+ };
+ void foo(const NonCopyable&);
+ void bar() {
+ foo(NonCopyable()); // Disallowed in C++98; allowed in C++11.
+ }
+
+ ::
+
+ struct NonCopyable2 {
+ NonCopyable2();
+ NonCopyable2(NonCopyable2&);
+ };
+ void foo(const NonCopyable2&);
+ void bar() {
+ foo(NonCopyable2()); // Disallowed in C++98; allowed in C++11.
+ }
+
+ Note that if ``NonCopyable2::NonCopyable2()`` has a default argument
+ whose instantiation produces a compile error, that error will still
+ be a hard error in C++98 mode even if this warning is turned off.
+
+Options to Control Clang Crash Diagnostics
+------------------------------------------
+
+As unbelievable as it may sound, Clang does crash from time to time.
+Generally, this only occurs to those living on the `bleeding
+edge <http://llvm.org/releases/download.html#svn>`_. Clang goes to great
+lengths to assist you in filing a bug report. Specifically, Clang
+generates preprocessed source file(s) and associated run script(s) upon
+a crash. These files should be attached to a bug report to ease
+reproducibility of the failure. Below are the command line options to
+control the crash diagnostics.
+
+.. option:: -fno-crash-diagnostics
+
+ Disable auto-generation of preprocessed source files during a clang crash.
+
+The -fno-crash-diagnostics flag can be helpful for speeding the process
+of generating a delta reduced test case.
+
+Clang is also capable of generating preprocessed source file(s) and associated
+run script(s) even without a crash. This is specially useful when trying to
+generate a reproducer for warnings or errors while using modules.
+
+.. option:: -gen-reproducer
+
+ Generates preprocessed source files, a reproducer script and if relevant, a
+ cache containing: built module pcm's and all headers needed to rebuilt the
+ same modules.
+
+.. _rpass:
+
+Options to Emit Optimization Reports
+------------------------------------
+
+Optimization reports trace, at a high-level, all the major decisions
+done by compiler transformations. For instance, when the inliner
+decides to inline function ``foo()`` into ``bar()``, or the loop unroller
+decides to unroll a loop N times, or the vectorizer decides to
+vectorize a loop body.
+
+Clang offers a family of flags which the optimizers can use to emit
+a diagnostic in three cases:
+
+1. When the pass makes a transformation (`-Rpass`).
+
+2. When the pass fails to make a transformation (`-Rpass-missed`).
+
+3. When the pass determines whether or not to make a transformation
+ (`-Rpass-analysis`).
+
+NOTE: Although the discussion below focuses on `-Rpass`, the exact
+same options apply to `-Rpass-missed` and `-Rpass-analysis`.
+
+Since there are dozens of passes inside the compiler, each of these flags
+take a regular expression that identifies the name of the pass which should
+emit the associated diagnostic. For example, to get a report from the inliner,
+compile the code with:
+
+.. code-block:: console
+
+ $ clang -O2 -Rpass=inline code.cc -o code
+ code.cc:4:25: remark: foo inlined into bar [-Rpass=inline]
+ int bar(int j) { return foo(j, j - 2); }
+ ^
+
+Note that remarks from the inliner are identified with `[-Rpass=inline]`.
+To request a report from every optimization pass, you should use
+`-Rpass=.*` (in fact, you can use any valid POSIX regular
+expression). However, do not expect a report from every transformation
+made by the compiler. Optimization remarks do not really make sense
+outside of the major transformations (e.g., inlining, vectorization,
+loop optimizations) and not every optimization pass supports this
+feature.
+
+Note that when using profile-guided optimization information, profile hotness
+information can be included in the remarks (see
+:ref:`-fdiagnostics-show-hotness <opt_fdiagnostics-show-hotness>`).
+
+Current limitations
+^^^^^^^^^^^^^^^^^^^
+
+1. Optimization remarks that refer to function names will display the
+ mangled name of the function. Since these remarks are emitted by the
+ back end of the compiler, it does not know anything about the input
+ language, nor its mangling rules.
+
+2. Some source locations are not displayed correctly. The front end has
+ a more detailed source location tracking than the locations included
+ in the debug info (e.g., the front end can locate code inside macro
+ expansions). However, the locations used by `-Rpass` are
+ translated from debug annotations. That translation can be lossy,
+ which results in some remarks having no location information.
+
+Other Options
+-------------
+Clang options that that don't fit neatly into other categories.
+
+.. option:: -MV
+
+ When emitting a dependency file, use formatting conventions appropriate
+ for NMake or Jom. Ignored unless another option causes Clang to emit a
+ dependency file.
+
+When Clang emits a dependency file (e.g., you supplied the -M option)
+most filenames can be written to the file without any special formatting.
+Different Make tools will treat different sets of characters as "special"
+and use different conventions for telling the Make tool that the character
+is actually part of the filename. Normally Clang uses backslash to "escape"
+a special character, which is the convention used by GNU Make. The -MV
+option tells Clang to put double-quotes around the entire filename, which
+is the convention used by NMake and Jom.
+
+
+Language and Target-Independent Features
+========================================
+
+Controlling Errors and Warnings
+-------------------------------
+
+Clang provides a number of ways to control which code constructs cause
+it to emit errors and warning messages, and how they are displayed to
+the console.
+
+Controlling How Clang Displays Diagnostics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When Clang emits a diagnostic, it includes rich information in the
+output, and gives you fine-grain control over which information is
+printed. Clang has the ability to print this information, and these are
+the options that control it:
+
+#. A file/line/column indicator that shows exactly where the diagnostic
+ occurs in your code [:ref:`-fshow-column <opt_fshow-column>`,
+ :ref:`-fshow-source-location <opt_fshow-source-location>`].
+#. A categorization of the diagnostic as a note, warning, error, or
+ fatal error.
+#. A text string that describes what the problem is.
+#. An option that indicates how to control the diagnostic (for
+ diagnostics that support it)
+ [:ref:`-fdiagnostics-show-option <opt_fdiagnostics-show-option>`].
+#. A :ref:`high-level category <diagnostics_categories>` for the diagnostic
+ for clients that want to group diagnostics by class (for diagnostics
+ that support it)
+ [:ref:`-fdiagnostics-show-category <opt_fdiagnostics-show-category>`].
+#. The line of source code that the issue occurs on, along with a caret
+ and ranges that indicate the important locations
+ [:ref:`-fcaret-diagnostics <opt_fcaret-diagnostics>`].
+#. "FixIt" information, which is a concise explanation of how to fix the
+ problem (when Clang is certain it knows)
+ [:ref:`-fdiagnostics-fixit-info <opt_fdiagnostics-fixit-info>`].
+#. A machine-parsable representation of the ranges involved (off by
+ default)
+ [:ref:`-fdiagnostics-print-source-range-info <opt_fdiagnostics-print-source-range-info>`].
+
+For more information please see :ref:`Formatting of
+Diagnostics <cl_diag_formatting>`.
+
+Diagnostic Mappings
+^^^^^^^^^^^^^^^^^^^
+
+All diagnostics are mapped into one of these 6 classes:
+
+- Ignored
+- Note
+- Remark
+- Warning
+- Error
+- Fatal
+
+.. _diagnostics_categories:
+
+Diagnostic Categories
+^^^^^^^^^^^^^^^^^^^^^
+
+Though not shown by default, diagnostics may each be associated with a
+high-level category. This category is intended to make it possible to
+triage builds that produce a large number of errors or warnings in a
+grouped way.
+
+Categories are not shown by default, but they can be turned on with the
+:ref:`-fdiagnostics-show-category <opt_fdiagnostics-show-category>` option.
+When set to "``name``", the category is printed textually in the
+diagnostic output. When it is set to "``id``", a category number is
+printed. The mapping of category names to category id's can be obtained
+by running '``clang --print-diagnostic-categories``'.
+
+Controlling Diagnostics via Command Line Flags
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+TODO: -W flags, -pedantic, etc
+
+.. _pragma_gcc_diagnostic:
+
+Controlling Diagnostics via Pragmas
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Clang can also control what diagnostics are enabled through the use of
+pragmas in the source code. This is useful for turning off specific
+warnings in a section of source code. Clang supports GCC's pragma for
+compatibility with existing source code, as well as several extensions.
+
+The pragma may control any warning that can be used from the command
+line. Warnings may be set to ignored, warning, error, or fatal. The
+following example code will tell Clang or GCC to ignore the -Wall
+warnings:
+
+.. code-block:: c
+
+ #pragma GCC diagnostic ignored "-Wall"
+
+In addition to all of the functionality provided by GCC's pragma, Clang
+also allows you to push and pop the current warning state. This is
+particularly useful when writing a header file that will be compiled by
+other people, because you don't know what warning flags they build with.
+
+In the below example :option:`-Wextra-tokens` is ignored for only a single line
+of code, after which the diagnostics return to whatever state had previously
+existed.
+
+.. code-block:: c
+
+ #if foo
+ #endif foo // warning: extra tokens at end of #endif directive
+
+ #pragma clang diagnostic push
+ #pragma clang diagnostic ignored "-Wextra-tokens"
+
+ #if foo
+ #endif foo // no warning
+
+ #pragma clang diagnostic pop
+
+The push and pop pragmas will save and restore the full diagnostic state
+of the compiler, regardless of how it was set. That means that it is
+possible to use push and pop around GCC compatible diagnostics and Clang
+will push and pop them appropriately, while GCC will ignore the pushes
+and pops as unknown pragmas. It should be noted that while Clang
+supports the GCC pragma, Clang and GCC do not support the exact same set
+of warnings, so even when using GCC compatible #pragmas there is no
+guarantee that they will have identical behaviour on both compilers.
+
+In addition to controlling warnings and errors generated by the compiler, it is
+possible to generate custom warning and error messages through the following
+pragmas:
+
+.. code-block:: c
+
+ // The following will produce warning messages
+ #pragma message "some diagnostic message"
+ #pragma GCC warning "TODO: replace deprecated feature"
+
+ // The following will produce an error message
+ #pragma GCC error "Not supported"
+
+These pragmas operate similarly to the ``#warning`` and ``#error`` preprocessor
+directives, except that they may also be embedded into preprocessor macros via
+the C99 ``_Pragma`` operator, for example:
+
+.. code-block:: c
+
+ #define STR(X) #X
+ #define DEFER(M,...) M(__VA_ARGS__)
+ #define CUSTOM_ERROR(X) _Pragma(STR(GCC error(X " at line " DEFER(STR,__LINE__))))
+
+ CUSTOM_ERROR("Feature not available");
+
+Controlling Diagnostics in System Headers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Warnings are suppressed when they occur in system headers. By default,
+an included file is treated as a system header if it is found in an
+include path specified by ``-isystem``, but this can be overridden in
+several ways.
+
+The ``system_header`` pragma can be used to mark the current file as
+being a system header. No warnings will be produced from the location of
+the pragma onwards within the same file.
+
+.. code-block:: c
+
+ #if foo
+ #endif foo // warning: extra tokens at end of #endif directive
+
+ #pragma clang system_header
+
+ #if foo
+ #endif foo // no warning
+
+The `--system-header-prefix=` and `--no-system-header-prefix=`
+command-line arguments can be used to override whether subsets of an include
+path are treated as system headers. When the name in a ``#include`` directive
+is found within a header search path and starts with a system prefix, the
+header is treated as a system header. The last prefix on the
+command-line which matches the specified header name takes precedence.
+For instance:
+
+.. code-block:: console
+
+ $ clang -Ifoo -isystem bar --system-header-prefix=x/ \
+ --no-system-header-prefix=x/y/
+
+Here, ``#include "x/a.h"`` is treated as including a system header, even
+if the header is found in ``foo``, and ``#include "x/y/b.h"`` is treated
+as not including a system header, even if the header is found in
+``bar``.
+
+A ``#include`` directive which finds a file relative to the current
+directory is treated as including a system header if the including file
+is treated as a system header.
+
+.. _diagnostics_enable_everything:
+
+Enabling All Diagnostics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In addition to the traditional ``-W`` flags, one can enable **all**
+diagnostics by passing :option:`-Weverything`. This works as expected
+with
+:option:`-Werror`, and also includes the warnings from :option:`-pedantic`.
+
+Note that when combined with :option:`-w` (which disables all warnings), that
+flag wins.
+
+Controlling Static Analyzer Diagnostics
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+While not strictly part of the compiler, the diagnostics from Clang's
+`static analyzer <http://clang-analyzer.llvm.org>`_ can also be
+influenced by the user via changes to the source code. See the available
+`annotations <http://clang-analyzer.llvm.org/annotations.html>`_ and the
+analyzer's `FAQ
+page <http://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>`__
+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
+some of the work needed to process a corresponding header file. While
+details of precompiled headers vary between compilers, precompiled
+headers have been shown to be highly effective at speeding up program
+compilation on systems with very large system headers (e.g., Mac OS X).
+
+Generating a PCH File
+^^^^^^^^^^^^^^^^^^^^^
+
+To generate a PCH file using Clang, one invokes Clang with the
+`-x <language>-header` option. This mirrors the interface in GCC
+for generating PCH files:
+
+.. code-block:: console
+
+ $ gcc -x c-header test.h -o test.h.gch
+ $ clang -x c-header test.h -o test.h.pch
+
+Using a PCH File
+^^^^^^^^^^^^^^^^
+
+A PCH file can then be used as a prefix header when a :option:`-include`
+option is passed to ``clang``:
+
+.. code-block:: console
+
+ $ clang -include test.h test.c -o test
+
+The ``clang`` driver will first check if a PCH file for ``test.h`` is
+available; if so, the contents of ``test.h`` (and the files it includes)
+will be processed from the PCH file. Otherwise, Clang falls back to
+directly processing the content of ``test.h``. This mirrors the behavior
+of GCC.
+
+.. note::
+
+ Clang does *not* automatically use PCH files for headers that are directly
+ included within a source file. For example:
+
+ .. code-block:: console
+
+ $ clang -x c-header test.h -o test.h.pch
+ $ cat test.c
+ #include "test.h"
+ $ clang test.c -o test
+
+ In this example, ``clang`` will not automatically use the PCH file for
+ ``test.h`` since ``test.h`` was included directly in the source file and not
+ specified on the command line using :option:`-include`.
+
+Relocatable PCH Files
+^^^^^^^^^^^^^^^^^^^^^
+
+It is sometimes necessary to build a precompiled header from headers
+that are not yet in their final, installed locations. For example, one
+might build a precompiled header within the build tree that is then
+meant to be installed alongside the headers. Clang permits the creation
+of "relocatable" precompiled headers, which are built with a given path
+(into the build directory) and can later be used from an installed
+location.
+
+To build a relocatable precompiled header, place your headers into a
+subdirectory whose structure mimics the installed location. For example,
+if you want to build a precompiled header for the header ``mylib.h``
+that will be installed into ``/usr/include``, create a subdirectory
+``build/usr/include`` and place the header ``mylib.h`` into that
+subdirectory. If ``mylib.h`` depends on other headers, then they can be
+stored within ``build/usr/include`` in a way that mimics the installed
+location.
+
+Building a relocatable precompiled header requires two additional
+arguments. First, pass the ``--relocatable-pch`` flag to indicate that
+the resulting PCH file should be relocatable. Second, pass
+`-isysroot /path/to/build`, which makes all includes for your library
+relative to the build directory. For example:
+
+.. code-block:: console
+
+ # clang -x c-header --relocatable-pch -isysroot /path/to/build /path/to/build/mylib.h mylib.h.pch
+
+When loading the relocatable PCH file, the various headers used in the
+PCH file are found from the system header root. For example, ``mylib.h``
+can be found in ``/usr/include/mylib.h``. If the headers are installed
+in some other system root, the `-isysroot` option can be used provide
+a different system root from which the headers will be based. For
+example, `-isysroot /Developer/SDKs/MacOSX10.4u.sdk` will look for
+``mylib.h`` in ``/Developer/SDKs/MacOSX10.4u.sdk/usr/include/mylib.h``.
+
+Relocatable precompiled headers are intended to be used in a limited
+number of cases where the compilation environment is tightly controlled
+and the precompiled header cannot be generated after headers have been
+installed.
+
+.. _controlling-code-generation:
+
+Controlling Code Generation
+---------------------------
+
+Clang provides a number of ways to control code generation. The options
+are listed below.
+
+**-f[no-]sanitize=check1,check2,...**
+ Turn on runtime checks for various forms of undefined or suspicious
+ behavior.
+
+ This option controls whether Clang adds runtime checks for various
+ forms of undefined or suspicious behavior, and is disabled by
+ default. If a check fails, a diagnostic message is produced at
+ runtime explaining the problem. The main checks are:
+
+ - .. _opt_fsanitize_address:
+
+ ``-fsanitize=address``:
+ :doc:`AddressSanitizer`, a memory error
+ detector.
+ - .. _opt_fsanitize_thread:
+
+ ``-fsanitize=thread``: :doc:`ThreadSanitizer`, a data race detector.
+ - .. _opt_fsanitize_memory:
+
+ ``-fsanitize=memory``: :doc:`MemorySanitizer`,
+ a detector of uninitialized reads. Requires instrumentation of all
+ program code.
+ - .. _opt_fsanitize_undefined:
+
+ ``-fsanitize=undefined``: :doc:`UndefinedBehaviorSanitizer`,
+ a fast and compatible undefined behavior checker.
+
+ - ``-fsanitize=dataflow``: :doc:`DataFlowSanitizer`, a general data
+ flow analysis.
+ - ``-fsanitize=cfi``: :doc:`control flow integrity <ControlFlowIntegrity>`
+ checks. Requires ``-flto``.
+ - ``-fsanitize=safe-stack``: :doc:`safe stack <SafeStack>`
+ protection against stack-based memory corruption errors.
+
+ There are more fine-grained checks available: see
+ the :ref:`list <ubsan-checks>` of specific kinds of
+ undefined behavior that can be detected and the :ref:`list <cfi-schemes>`
+ of control flow integrity schemes.
+
+ The ``-fsanitize=`` argument must also be provided when linking, in
+ order to link to the appropriate runtime library.
+
+ It is not possible to combine more than one of the ``-fsanitize=address``,
+ ``-fsanitize=thread``, and ``-fsanitize=memory`` checkers in the same
+ program.
+
+**-f[no-]sanitize-recover=check1,check2,...**
+
+**-f[no-]sanitize-recover=all**
+
+ Controls which checks enabled by ``-fsanitize=`` flag are non-fatal.
+ If the check is fatal, program will halt after the first error
+ of this kind is detected and error report is printed.
+
+ By default, non-fatal checks are those enabled by
+ :doc:`UndefinedBehaviorSanitizer`,
+ except for ``-fsanitize=return`` and ``-fsanitize=unreachable``. Some
+ sanitizers may not support recovery (or not support it by default
+ e.g. :doc:`AddressSanitizer`), and always crash the program after the issue
+ is detected.
+
+ Note that the ``-fsanitize-trap`` flag has precedence over this flag.
+ This means that if a check has been configured to trap elsewhere on the
+ command line, or if the check traps by default, this flag will not have
+ any effect unless that sanitizer's trapping behavior is disabled with
+ ``-fno-sanitize-trap``.
+
+ For example, if a command line contains the flags ``-fsanitize=undefined
+ -fsanitize-trap=undefined``, the flag ``-fsanitize-recover=alignment``
+ will have no effect on its own; it will need to be accompanied by
+ ``-fno-sanitize-trap=alignment``.
+
+**-f[no-]sanitize-trap=check1,check2,...**
+
+ Controls which checks enabled by the ``-fsanitize=`` flag trap. This
+ option is intended for use in cases where the sanitizer runtime cannot
+ be used (for instance, when building libc or a kernel module), or where
+ the binary size increase caused by the sanitizer runtime is a concern.
+
+ This flag is only compatible with :doc:`control flow integrity
+ <ControlFlowIntegrity>` schemes and :doc:`UndefinedBehaviorSanitizer`
+ checks other than ``vptr``. If this flag
+ is supplied together with ``-fsanitize=undefined``, the ``vptr`` sanitizer
+ will be implicitly disabled.
+
+ This flag is enabled by default for sanitizers in the ``cfi`` group.
+
+.. option:: -fsanitize-blacklist=/path/to/blacklist/file
+
+ Disable or modify sanitizer checks for objects (source files, functions,
+ variables, types) listed in the file. See
+ :doc:`SanitizerSpecialCaseList` for file format description.
+
+.. option:: -fno-sanitize-blacklist
+
+ Don't use blacklist file, if it was specified earlier in the command line.
+
+**-f[no-]sanitize-coverage=[type,features,...]**
+
+ Enable simple code coverage in addition to certain sanitizers.
+ See :doc:`SanitizerCoverage` for more details.
+
+**-f[no-]sanitize-stats**
+
+ Enable simple statistics gathering for the enabled sanitizers.
+ See :doc:`SanitizerStats` for more details.
+
+.. option:: -fsanitize-undefined-trap-on-error
+
+ Deprecated alias for ``-fsanitize-trap=undefined``.
+
+.. option:: -fsanitize-cfi-cross-dso
+
+ Enable cross-DSO control flow integrity checks. This flag modifies
+ the behavior of sanitizers in the ``cfi`` group to allow checking
+ of cross-DSO virtual and indirect calls.
+
+
+.. option:: -fstrict-vtable-pointers
+
+ Enable optimizations based on the strict rules for overwriting polymorphic
+ C++ objects, i.e. the vptr is invariant during an object's lifetime.
+ This enables better devirtualization. Turned off by default, because it is
+ still experimental.
+
+.. option:: -ffast-math
+
+ Enable fast-math mode. This defines the ``__FAST_MATH__`` preprocessor
+ macro, and lets the compiler make aggressive, potentially-lossy assumptions
+ about floating-point math. These include:
+
+ * Floating-point math obeys regular algebraic rules for real numbers (e.g.
+ ``+`` and ``*`` are associative, ``x/y == x * (1/y)``, and
+ ``(a + b) * c == a * c + b * c``),
+ * operands to floating-point operations are not equal to ``NaN`` and
+ ``Inf``, and
+ * ``+0`` and ``-0`` are interchangeable.
+
+.. option:: -fdenormal-fp-math=[values]
+
+ Select which denormal numbers the code is permitted to require.
+
+ Valid values are: ``ieee``, ``preserve-sign``, and ``positive-zero``,
+ which correspond to IEEE 754 denormal numbers, the sign of a
+ flushed-to-zero number is preserved in the sign of 0, denormals are
+ flushed to positive zero, respectively.
+
+.. option:: -fwhole-program-vtables
+
+ Enable whole-program vtable optimizations, such as single-implementation
+ devirtualization and virtual constant propagation, for classes with
+ :doc:`hidden LTO visibility <LTOVisibility>`. Requires ``-flto``.
+
+.. option:: -fno-assume-sane-operator-new
+
+ Don't assume that the C++'s new operator is sane.
+
+ This option tells the compiler to do not assume that C++'s global
+ new operator will always return a pointer that does not alias any
+ other pointer when the function returns.
+
+.. option:: -ftrap-function=[name]
+
+ Instruct code generator to emit a function call to the specified
+ function name for ``__builtin_trap()``.
+
+ LLVM code generator translates ``__builtin_trap()`` to a trap
+ instruction if it is supported by the target ISA. Otherwise, the
+ builtin is translated into a call to ``abort``. If this option is
+ set, then the code generator will always lower the builtin to a call
+ to the specified function regardless of whether the target ISA has a
+ trap instruction. This option is useful for environments (e.g.
+ deeply embedded) where a trap cannot be properly handled, or when
+ some custom behavior is desired.
+
+.. option:: -ftls-model=[model]
+
+ Select which TLS model to use.
+
+ Valid values are: ``global-dynamic``, ``local-dynamic``,
+ ``initial-exec`` and ``local-exec``. The default value is
+ ``global-dynamic``. The compiler may use a different model if the
+ selected model is not supported by the target, or if a more
+ efficient model can be used. The TLS model can be overridden per
+ variable using the ``tls_model`` attribute.
+
+.. option:: -femulated-tls
+
+ Select emulated TLS model, which overrides all -ftls-model choices.
+
+ In emulated TLS mode, all access to TLS variables are converted to
+ calls to __emutls_get_address in the runtime library.
+
+.. option:: -mhwdiv=[values]
+
+ Select the ARM modes (arm or thumb) that support hardware division
+ instructions.
+
+ Valid values are: ``arm``, ``thumb`` and ``arm,thumb``.
+ This option is used to indicate which mode (arm or thumb) supports
+ hardware division instructions. This only applies to the ARM
+ architecture.
+
+.. option:: -m[no-]crc
+
+ Enable or disable CRC instructions.
+
+ This option is used to indicate whether CRC instructions are to
+ be generated. This only applies to the ARM architecture.
+
+ CRC instructions are enabled by default on ARMv8.
+
+.. option:: -mgeneral-regs-only
+
+ Generate code which only uses the general purpose registers.
+
+ This option restricts the generated code to use general registers
+ only. This only applies to the AArch64 architecture.
+
+.. option:: -mcompact-branches=[values]
+
+ Control the usage of compact branches for MIPSR6.
+
+ Valid values are: ``never``, ``optimal`` and ``always``.
+ The default value is ``optimal`` which generates compact branches
+ when a delay slot cannot be filled. ``never`` disables the usage of
+ compact branches and ``always`` generates compact branches whenever
+ possible.
+
+**-f[no-]max-type-align=[number]**
+ Instruct the code generator to not enforce a higher alignment than the given
+ number (of bytes) when accessing memory via an opaque pointer or reference.
+ This cap is ignored when directly accessing a variable or when the pointee
+ type has an explicit âalignedâ attribute.
+
+ The value should usually be determined by the properties of the system allocator.
+ Some builtin types, especially vector types, have very high natural alignments;
+ when working with values of those types, Clang usually wants to use instructions
+ that take advantage of that alignment. However, many system allocators do
+ not promise to return memory that is more than 8-byte or 16-byte-aligned. Use
+ this option to limit the alignment that the compiler can assume for an arbitrary
+ pointer, which may point onto the heap.
+
+ This option does not affect the ABI alignment of types; the layout of structs and
+ unions and the value returned by the alignof operator remain the same.
+
+ This option can be overridden on a case-by-case basis by putting an explicit
+ âalignedâ alignment on a struct, union, or typedef. For example:
+
+ .. code-block:: console
+
+ #include <immintrin.h>
+ // Make an aligned typedef of the AVX-512 16-int vector type.
+ typedef __v16si __aligned_v16si __attribute__((aligned(64)));
+
+ void initialize_vector(__aligned_v16si *v) {
+ // The compiler may assume that âvâ is 64-byte aligned, regardless of the
+ // value of -fmax-type-align.
+ }
+
+
+Profile Guided Optimization
+---------------------------
+
+Profile information enables better optimization. For example, knowing that a
+branch is taken very frequently helps the compiler make better decisions when
+ordering basic blocks. Knowing that a function ``foo`` is called more
+frequently than another function ``bar`` helps the inliner.
+
+Clang supports profile guided optimization with two different kinds of
+profiling. A sampling profiler can generate a profile with very low runtime
+overhead, or you can build an instrumented version of the code that collects
+more detailed profile information. Both kinds of profiles can provide execution
+counts for instructions in the code and information on branches taken and
+function invocation.
+
+Regardless of which kind of profiling you use, be careful to collect profiles
+by running your code with inputs that are representative of the typical
+behavior. Code that is not exercised in the profile will be optimized as if it
+is unimportant, and the compiler may make poor optimization choices for code
+that is disproportionately used while profiling.
+
+Differences Between Sampling and Instrumentation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Although both techniques are used for similar purposes, there are important
+differences between the two:
+
+1. Profile data generated with one cannot be used by the other, and there is no
+ conversion tool that can convert one to the other. So, a profile generated
+ via ``-fprofile-instr-generate`` must be used with ``-fprofile-instr-use``.
+ Similarly, sampling profiles generated by external profilers must be
+ converted and used with ``-fprofile-sample-use``.
+
+2. Instrumentation profile data can be used for code coverage analysis and
+ optimization.
+
+3. Sampling profiles can only be used for optimization. They cannot be used for
+ code coverage analysis. Although it would be technically possible to use
+ sampling profiles for code coverage, sample-based profiles are too
+ coarse-grained for code coverage purposes; it would yield poor results.
+
+4. Sampling profiles must be generated by an external tool. The profile
+ generated by that tool must then be converted into a format that can be read
+ by LLVM. The section on sampling profilers describes one of the supported
+ sampling profile formats.
+
+
+Using Sampling Profilers
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Sampling profilers are used to collect runtime information, such as
+hardware counters, while your application executes. They are typically
+very efficient and do not incur a large runtime overhead. The
+sample data collected by the profiler can be used during compilation
+to determine what the most executed areas of the code are.
+
+Using the data from a sample profiler requires some changes in the way
+a program is built. Before the compiler can use profiling information,
+the code needs to execute under the profiler. The following is the
+usual build cycle when using sample profilers for optimization:
+
+1. Build the code with source line table information. You can use all the
+ usual build flags that you always build your application with. The only
+ requirement is that you add ``-gline-tables-only`` or ``-g`` to the
+ command line. This is important for the profiler to be able to map
+ instructions back to source line locations.
+
+ .. code-block:: console
+
+ $ clang++ -O2 -gline-tables-only code.cc -o code
+
+2. Run the executable under a sampling profiler. The specific profiler
+ you use does not really matter, as long as its output can be converted
+ into the format that the LLVM optimizer understands. Currently, there
+ exists a conversion tool for the Linux Perf profiler
+ (https://perf.wiki.kernel.org/), so these examples assume that you
+ are using Linux Perf to profile your code.
+
+ .. code-block:: console
+
+ $ perf record -b ./code
+
+ 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
+ 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
+ the profile data in ``code.prof``. Note that if you ran ``perf``
+ without the ``-b`` flag, you need to use ``--use_lbr=false`` when
+ calling ``create_llvm_prof``.
+
+4. Build the code again using the collected profile. This step feeds
+ the profile back to the optimizers. This should result in a binary
+ that executes faster than the original one. Note that you are not
+ required to build the code with the exact same arguments that you
+ used in the first step. The only requirement is that you build the code
+ with ``-gline-tables-only`` and ``-fprofile-sample-use``.
+
+ .. code-block:: console
+
+ $ clang++ -O2 -gline-tables-only -fprofile-sample-use=code.prof code.cc -o code
+
+
+Sample Profile Formats
+""""""""""""""""""""""
+
+Since external profilers generate profile data in a variety of custom formats,
+the data generated by the profiler must be converted into a format that can be
+read by the backend. LLVM supports three different sample profile formats:
+
+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.
+
+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
+ ``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.
+
+
+Sample Profile Text Format
+""""""""""""""""""""""""""
+
+This section describes the ASCII text format for sampling profiles. It is,
+arguably, the easiest one to generate. If you are interested in generating any
+of the other two, consult the ``ProfileData`` library in in LLVM's source tree
+(specifically, ``include/llvm/ProfileData/SampleProfReader.h``).
+
+.. code-block:: console
+
+ function1:total_samples:total_head_samples
+ offset1[.discriminator]: number_of_samples [fn1:num fn2:num ... ]
+ offset2[.discriminator]: number_of_samples [fn3:num fn4:num ... ]
+ ...
+ offsetN[.discriminator]: number_of_samples [fn5:num fn6:num ... ]
+ offsetA[.discriminator]: fnA:num_of_total_samples
+ offsetA1[.discriminator]: number_of_samples [fn7:num fn8:num ... ]
+ offsetA1[.discriminator]: number_of_samples [fn9:num fn10:num ... ]
+ offsetB[.discriminator]: fnB:num_of_total_samples
+ offsetB1[.discriminator]: number_of_samples [fn11:num fn12:num ... ]
+
+This is a nested tree in which the identation represents the nesting level
+of the inline stack. There are no blank lines in the file. And the spacing
+within a single line is fixed. Additional spaces will result in an error
+while reading the file.
+
+Any line starting with the '#' character is completely ignored.
+
+Inlined calls are represented with indentation. The Inline stack is a
+stack of source locations in which the top of the stack represents the
+leaf function, and the bottom of the stack represents the actual
+symbol to which the instruction belongs.
+
+Function names must be mangled in order for the profile loader to
+match them in the current translation unit. The two numbers in the
+function header specify how many total samples were accumulated in the
+function (first number), and the total number of samples accumulated
+in the prologue of the function (second number). This head sample
+count provides an indicator of how frequently the function is invoked.
+
+There are two types of lines in the function body.
+
+- Sampled line represents the profile information of a source location.
+ ``offsetN[.discriminator]: number_of_samples [fn5:num fn6:num ... ]``
+
+- Callsite line represents the profile information of an inlined callsite.
+ ``offsetA[.discriminator]: fnA:num_of_total_samples``
+
+Each sampled line may contain several items. Some are optional (marked
+below):
+
+a. Source line offset. This number represents the line number
+ in the function where the sample was collected. The line number is
+ always relative to the line where symbol of the function is
+ defined. So, if the function has its header at line 280, the offset
+ 13 is at line 293 in the file.
+
+ Note that this offset should never be a negative number. This could
+ happen in cases like macros. The debug machinery will register the
+ line number at the point of macro expansion. So, if the macro was
+ expanded in a line before the start of the function, the profile
+ converter should emit a 0 as the offset (this means that the optimizers
+ will not be able to associate a meaningful weight to the instructions
+ in the macro).
+
+b. [OPTIONAL] Discriminator. This is used if the sampled program
+ was compiled with DWARF discriminator support
+ (http://wiki.dwarfstd.org/index.php?title=Path_Discriminators).
+ DWARF discriminators are unsigned integer values that allow the
+ compiler to distinguish between multiple execution paths on the
+ same source line location.
+
+ For example, consider the line of code ``if (cond) foo(); else bar();``.
+ If the predicate ``cond`` is true 80% of the time, then the edge
+ into function ``foo`` should be considered to be taken most of the
+ time. But both calls to ``foo`` and ``bar`` are at the same source
+ line, so a sample count at that line is not sufficient. The
+ compiler needs to know which part of that line is taken more
+ frequently.
+
+ This is what discriminators provide. In this case, the calls to
+ ``foo`` and ``bar`` will be at the same line, but will have
+ different discriminator values. This allows the compiler to correctly
+ set edge weights into ``foo`` and ``bar``.
+
+c. Number of samples. This is an integer quantity representing the
+ number of samples collected by the profiler at this source
+ location.
+
+d. [OPTIONAL] Potential call targets and samples. If present, this
+ line contains a call instruction. This models both direct and
+ number of samples. For example,
+
+ .. code-block:: console
+
+ 130: 7 foo:3 bar:2 baz:7
+
+ The above means that at relative line offset 130 there is a call
+ instruction that calls one of ``foo()``, ``bar()`` and ``baz()``,
+ with ``baz()`` being the relatively more frequently called target.
+
+As an example, consider a program with the call chain ``main -> foo -> bar``.
+When built with optimizations enabled, the compiler may inline the
+calls to ``bar`` and ``foo`` inside ``main``. The generated profile
+could then be something like this:
+
+.. code-block:: console
+
+ main:35504:0
+ 1: _Z3foov:35504
+ 2: _Z32bari:31977
+ 1.1: 31977
+ 2: 0
+
+This profile indicates that there were a total of 35,504 samples
+collected in main. All of those were at line 1 (the call to ``foo``).
+Of those, 31,977 were spent inside the body of ``bar``. The last line
+of the profile (``2: 0``) corresponds to line 2 inside ``main``. No
+samples were collected there.
+
+Profiling with Instrumentation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Clang also supports profiling via instrumentation. This requires building a
+special instrumented version of the code and has some runtime
+overhead during the profiling, but it provides more detailed results than a
+sampling profiler. It also provides reproducible results, at least to the
+extent that the code behaves consistently across runs.
+
+Here are the steps for using profile guided optimization with
+instrumentation:
+
+1. Build an instrumented version of the code by compiling and linking with the
+ ``-fprofile-instr-generate`` option.
+
+ .. code-block:: console
+
+ $ clang++ -O2 -fprofile-instr-generate code.cc -o code
+
+2. Run the instrumented executable with inputs that reflect the typical usage.
+ By default, the profile data will be written to a ``default.profraw`` file
+ in the current directory. You can override that default by using option
+ ``-fprofile-instr-generate=`` or by setting the ``LLVM_PROFILE_FILE``
+ environment variable to specify an alternate file. If non-default file name
+ is specified by both the environment variable and the command line option,
+ the environment variable takes precedence. The file name pattern specified
+ can include different modifiers: ``%p``, ``%h``, and ``%m``.
+
+ Any instance of ``%p`` in that file name will be replaced by the process
+ ID, so that you can easily distinguish the profile output from multiple
+ runs.
+
+ .. code-block:: console
+
+ $ LLVM_PROFILE_FILE="code-%p.profraw" ./code
+
+ The modifier ``%h`` can be used in scenarios where the same instrumented
+ binary is run in multiple different host machines dumping profile data
+ to a shared network based storage. The ``%h`` specifier will be substituted
+ with the hostname so that profiles collected from different hosts do not
+ clobber each other.
+
+ While the use of ``%p`` specifier can reduce the likelihood for the profiles
+ dumped from different processes to clobber each other, such clobbering can still
+ happen because of the ``pid`` re-use by the OS. Another side-effect of using
+ ``%p`` is that the storage requirement for raw profile data files is greatly
+ increased. To avoid issues like this, the ``%m`` specifier can used in the profile
+ name. When this specifier is used, the profiler runtime will substitute ``%m``
+ with a unique integer identifier associated with the instrumented binary. Additionally,
+ multiple raw profiles dumped from different processes that share a file system (can be
+ on different hosts) will be automatically merged by the profiler runtime during the
+ dumping. If the program links in multiple instrumented shared libraries, each library
+ will dump the profile data into its own profile data file (with its unique integer
+ id embedded in the profile name). Note that the merging enabled by ``%m`` is for raw
+ profile data generated by profiler runtime. The resulting merged "raw" profile data
+ file still needs to be converted to a different format expected by the compiler (
+ see step 3 below).
+
+ .. code-block:: console
+
+ $ LLVM_PROFILE_FILE="code-%m.profraw" ./code
+
+
+3. Combine profiles from multiple runs and convert the "raw" profile format to
+ the input expected by clang. Use the ``merge`` command of the
+ ``llvm-profdata`` tool to do this.
+
+ .. code-block:: console
+
+ $ llvm-profdata merge -output=code.profdata code-*.profraw
+
+ Note that this step is necessary even when there is only one "raw" profile,
+ since the merge operation also changes the file format.
+
+4. Build the code again using the ``-fprofile-instr-use`` option to specify the
+ collected profile data.
+
+ .. code-block:: console
+
+ $ clang++ -O2 -fprofile-instr-use=code.profdata code.cc -o code
+
+ You can repeat step 4 as often as you like without regenerating the
+ profile. As you make changes to your code, clang may no longer be able to
+ use the profile data. It will warn you when this happens.
+
+Profile generation using an alternative instrumentation method can be
+controlled by the GCC-compatible flags ``-fprofile-generate`` and
+``-fprofile-use``. Although these flags are semantically equivalent to
+their GCC counterparts, they *do not* handle GCC-compatible profiles.
+They are only meant to implement GCC's semantics with respect to
+profile creation and use.
+
+.. option:: -fprofile-generate[=<dirname>]
+
+ The ``-fprofile-generate`` and ``-fprofile-generate=`` flags will use
+ an alterantive instrumentation method for profile generation. When
+ given a directory name, it generates the profile file
+ ``default_%m.profraw`` in the directory named ``dirname`` if specified.
+ If ``dirname`` does not exist, it will be created at runtime. ``%m`` specifier
+ will be substibuted with a unique id documented in step 2 above. In other words,
+ with ``-fprofile-generate[=<dirname>]`` option, the "raw" profile data automatic
+ merging is turned on by default, so there will no longer any risk of profile
+ clobbering from different running processes. For example,
+
+ .. code-block:: console
+
+ $ clang++ -O2 -fprofile-generate=yyy/zzz code.cc -o code
+
+ When ``code`` is executed, the profile will be written to the file
+ ``yyy/zzz/default_xxxx.profraw``.
+
+ To generate the profile data file with the compiler readable format, the
+ ``llvm-profdata`` tool can be used with the profile directory as the input:
+
+ .. code-block:: console
+
+ $ llvm-profdata merge -output=code.profdata yyy/zzz/
+
+ If the user wants to turn off the auto-merging feature, or simply override the
+ the profile dumping path specified at command line, the environment variable
+ ``LLVM_PROFILE_FILE`` can still be used to override
+ the directory and filename for the profile file at runtime.
+
+.. option:: -fprofile-use[=<pathname>]
+
+ Without any other arguments, ``-fprofile-use`` behaves identically to
+ ``-fprofile-instr-use``. Otherwise, if ``pathname`` is the full path to a
+ profile file, it reads from that file. If ``pathname`` is a directory name,
+ it reads from ``pathname/default.profdata``.
+
+Disabling Instrumentation
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In certain situations, it may be useful to disable profile generation or use
+for specific files in a build, without affecting the main compilation flags
+used for the other files in the project.
+
+In these cases, you can use the flag ``-fno-profile-instr-generate`` (or
+``-fno-profile-generate``) to disable profile generation, and
+``-fno-profile-instr-use`` (or ``-fno-profile-use``) to disable profile use.
+
+Note that these flags should appear after the corresponding profile
+flags to have an effect.
+
+Controlling Debug Information
+-----------------------------
+
+Controlling Size of Debug Information
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Debug info kind generated by Clang can be set by one of the flags listed
+below. If multiple flags are present, the last one is used.
+
+.. option:: -g0
+
+ Don't generate any debug info (default).
+
+.. option:: -gline-tables-only
+
+ Generate line number tables only.
+
+ This kind of debug info allows to obtain stack traces with function names,
+ file names and line numbers (by such tools as ``gdb`` or ``addr2line``). It
+ doesn't contain any other data (e.g. description of local variables or
+ function parameters).
+
+.. option:: -fstandalone-debug
+
+ Clang supports a number of optimizations to reduce the size of debug
+ information in the binary. They work based on the assumption that
+ the debug type information can be spread out over multiple
+ compilation units. For instance, Clang will not emit type
+ definitions for types that are not needed by a module and could be
+ replaced with a forward declaration. Further, Clang will only emit
+ type info for a dynamic C++ class in the module that contains the
+ vtable for the class.
+
+ The **-fstandalone-debug** option turns off these optimizations.
+ This is useful when working with 3rd-party libraries that don't come
+ with debug information. Note that Clang will never emit type
+ information for types that are not referenced at all by the program.
+
+.. option:: -fno-standalone-debug
+
+ On Darwin **-fstandalone-debug** is enabled by default. The
+ **-fno-standalone-debug** option can be used to get to turn on the
+ vtable-based optimization described above.
+
+.. option:: -g
+
+ Generate complete debug info.
+
+Controlling Macro Debug Info Generation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Debug info for C preprocessor macros increases the size of debug information in
+the binary. Macro debug info generated by Clang can be controlled by the flags
+listed below.
+
+.. option:: -fdebug-macro
+
+ Generate debug info for preprocessor macros. This flag is discarded when
+ **-g0** is enabled.
+
+.. option:: -fno-debug-macro
+
+ Do not generate debug info for preprocessor macros (default).
+
+Controlling Debugger "Tuning"
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+While Clang generally emits standard DWARF debug info (http://dwarfstd.org),
+different debuggers may know how to take advantage of different specific DWARF
+features. You can "tune" the debug info for one of several different debuggers.
+
+.. option:: -ggdb, -glldb, -gsce
+
+ Tune the debug info for the ``gdb``, ``lldb``, or Sony PlayStation\ |reg|
+ debugger, respectively. Each of these options implies **-g**. (Therefore, if
+ you want both **-gline-tables-only** and debugger tuning, the tuning option
+ must come first.)
+
+
+Comment Parsing Options
+-----------------------
+
+Clang parses Doxygen and non-Doxygen style documentation comments and attaches
+them to the appropriate declaration nodes. By default, it only parses
+Doxygen-style comments and ignores ordinary comments starting with ``//`` and
+``/*``.
+
+.. option:: -Wdocumentation
+
+ Emit warnings about use of documentation comments. This warning group is off
+ by default.
+
+ This includes checking that ``\param`` commands name parameters that actually
+ present in the function signature, checking that ``\returns`` is used only on
+ functions that actually return a value etc.
+
+.. option:: -Wno-documentation-unknown-command
+
+ Don't warn when encountering an unknown Doxygen command.
+
+.. option:: -fparse-all-comments
+
+ Parse all comments as documentation comments (including ordinary comments
+ starting with ``//`` and ``/*``).
+
+.. option:: -fcomment-block-commands=[commands]
+
+ Define custom documentation commands as block commands. This allows Clang to
+ construct the correct AST for these custom commands, and silences warnings
+ about unknown commands. Several commands must be separated by a comma
+ *without trailing space*; e.g. ``-fcomment-block-commands=foo,bar`` defines
+ custom commands ``\foo`` and ``\bar``.
+
+ It is also possible to use ``-fcomment-block-commands`` several times; e.g.
+ ``-fcomment-block-commands=foo -fcomment-block-commands=bar`` does the same
+ as above.
+
+.. _c:
+
+C Language Features
+===================
+
+The support for standard C in clang is feature-complete except for the
+C99 floating-point pragmas.
+
+Extensions supported by clang
+-----------------------------
+
+See :doc:`LanguageExtensions`.
+
+Differences between various standard modes
+------------------------------------------
+
+clang supports the -std option, which changes what language mode clang
+uses. The supported modes for C are c89, gnu89, c94, c99, gnu99, c11,
+gnu11, and various aliases for those modes. If no -std option is
+specified, clang defaults to gnu11 mode. Many C99 and C11 features are
+supported in earlier modes as a conforming extension, with a warning. Use
+``-pedantic-errors`` to request an error if a feature from a later standard
+revision is used in an earlier mode.
+
+Differences between all ``c*`` and ``gnu*`` modes:
+
+- ``c*`` modes define "``__STRICT_ANSI__``".
+- Target-specific defines not prefixed by underscores, like "linux",
+ are defined in ``gnu*`` modes.
+- Trigraphs default to being off in ``gnu*`` modes; they can be enabled by
+ the -trigraphs option.
+- The parser recognizes "asm" and "typeof" as keywords in ``gnu*`` modes;
+ the variants "``__asm__``" and "``__typeof__``" are recognized in all
+ modes.
+- The Apple "blocks" extension is recognized by default in ``gnu*`` modes
+ on some platforms; it can be enabled in any mode with the "-fblocks"
+ option.
+- Arrays that are VLA's according to the standard, but which can be
+ constant folded by the frontend are treated as fixed size arrays.
+ This occurs for things like "int X[(1, 2)];", which is technically a
+ VLA. ``c*`` modes are strictly compliant and treat these as VLAs.
+
+Differences between ``*89`` and ``*99`` modes:
+
+- The ``*99`` modes default to implementing "inline" as specified in C99,
+ while the ``*89`` modes implement the GNU version. This can be
+ overridden for individual functions with the ``__gnu_inline__``
+ attribute.
+- Digraphs are not recognized in c89 mode.
+- The scope of names defined inside a "for", "if", "switch", "while",
+ or "do" statement is different. (example: "``if ((struct x {int
+ x;}*)0) {}``".)
+- ``__STDC_VERSION__`` is not defined in ``*89`` modes.
+- "inline" is not recognized as a keyword in c89 mode.
+- "restrict" is not recognized as a keyword in ``*89`` modes.
+- Commas are allowed in integer constant expressions in ``*99`` modes.
+- Arrays which are not lvalues are not implicitly promoted to pointers
+ in ``*89`` modes.
+- Some warnings are different.
+
+Differences between ``*99`` and ``*11`` modes:
+
+- Warnings for use of C11 features are disabled.
+- ``__STDC_VERSION__`` is defined to ``201112L`` rather than ``199901L``.
+
+c94 mode is identical to c89 mode except that digraphs are enabled in
+c94 mode (FIXME: And ``__STDC_VERSION__`` should be defined!).
+
+GCC extensions not implemented yet
+----------------------------------
+
+clang tries to be compatible with gcc as much as possible, but some gcc
+extensions are not implemented yet:
+
+- clang does not support decimal floating point types (``_Decimal32`` and
+ friends) or fixed-point types (``_Fract`` and friends); nobody has
+ expressed interest in these features yet, so it's hard to say when
+ they will be implemented.
+- clang does not support nested functions; this is a complex feature
+ which is infrequently used, so it is unlikely to be implemented
+ anytime soon. In C++11 it can be emulated by assigning lambda
+ functions to local variables, e.g:
+
+ .. code-block:: cpp
+
+ auto const local_function = [&](int parameter) {
+ // Do something
+ };
+ ...
+ local_function(1);
+
+- clang only supports global register variables when the register specified
+ is non-allocatable (e.g. the stack pointer). Support for general global
+ register variables is unlikely to be implemented soon because it requires
+ additional LLVM backend support.
+- clang does not support static initialization of flexible array
+ members. This appears to be a rarely used extension, but could be
+ implemented pending user demand.
+- clang does not support
+ ``__builtin_va_arg_pack``/``__builtin_va_arg_pack_len``. This is
+ used rarely, but in some potentially interesting places, like the
+ glibc headers, so it may be implemented pending user demand. Note
+ that because clang pretends to be like GCC 4.2, and this extension
+ was introduced in 4.3, the glibc headers will not try to use this
+ extension with clang at the moment.
+- clang does not support the gcc extension for forward-declaring
+ function parameters; this has not shown up in any real-world code
+ yet, though, so it might never be implemented.
+
+This is not a complete list; if you find an unsupported extension
+missing from this list, please send an e-mail to cfe-dev. This list
+currently excludes C++; see :ref:`C++ Language Features <cxx>`. Also, this
+list does not include bugs in mostly-implemented features; please see
+the `bug
+tracker <https://bugs.llvm.org/buglist.cgi?quicksearch=product%3Aclang+component%3A-New%2BBugs%2CAST%2CBasic%2CDriver%2CHeaders%2CLLVM%2BCodeGen%2Cparser%2Cpreprocessor%2CSemantic%2BAnalyzer>`_
+for known existing bugs (FIXME: Is there a section for bug-reporting
+guidelines somewhere?).
+
+Intentionally unsupported GCC extensions
+----------------------------------------
+
+- clang does not support the gcc extension that allows variable-length
+ arrays in structures. This is for a few reasons: one, it is tricky to
+ implement, two, the extension is completely undocumented, and three,
+ the extension appears to be rarely used. Note that clang *does*
+ support flexible array members (arrays with a zero or unspecified
+ size at the end of a structure).
+- clang does not have an equivalent to gcc's "fold"; this means that
+ clang doesn't accept some constructs gcc might accept in contexts
+ where a constant expression is required, like "x-x" where x is a
+ variable.
+- clang does not support ``__builtin_apply`` and friends; this extension
+ is extremely obscure and difficult to implement reliably.
+
+.. _c_ms:
+
+Microsoft extensions
+--------------------
+
+clang has support for many extensions from Microsoft Visual C++. To enable these
+extensions, use the ``-fms-extensions`` command-line option. This is the default
+for Windows targets. Clang does not implement every pragma or declspec provided
+by MSVC, but the popular ones, such as ``__declspec(dllexport)`` and ``#pragma
+comment(lib)`` are well supported.
+
+clang has a ``-fms-compatibility`` flag that makes clang accept enough
+invalid C++ to be able to parse most Microsoft headers. For example, it
+allows `unqualified lookup of dependent base class members
+<http://clang.llvm.org/compatibility.html#dep_lookup_bases>`_, which is
+a common compatibility issue with clang. This flag is enabled by default
+for Windows targets.
+
+``-fdelayed-template-parsing`` lets clang delay parsing of function template
+definitions until the end of a translation unit. This flag is enabled by
+default for Windows targets.
+
+For compatibility with existing code that compiles with MSVC, clang defines the
+``_MSC_VER`` and ``_MSC_FULL_VER`` macros. These default to the values of 1800
+and 180000000 respectively, making clang look like an early release of Visual
+C++ 2013. The ``-fms-compatibility-version=`` flag overrides these values. It
+accepts a dotted version tuple, such as 19.00.23506. Changing the MSVC
+compatibility version makes clang behave more like that version of MSVC. For
+example, ``-fms-compatibility-version=19`` will enable C++14 features and define
+``char16_t`` and ``char32_t`` as builtin types.
+
+.. _cxx:
+
+C++ Language Features
+=====================
+
+clang fully implements all of standard C++98 except for exported
+templates (which were removed in C++11), and all of standard C++11
+and the current draft standard for C++1y.
+
+Controlling implementation limits
+---------------------------------
+
+.. option:: -fbracket-depth=N
+
+ Sets the limit for nested parentheses, brackets, and braces to N. The
+ default is 256.
+
+.. option:: -fconstexpr-depth=N
+
+ Sets the limit for recursive constexpr function invocations to N. The
+ default is 512.
+
+.. option:: -ftemplate-depth=N
+
+ Sets the limit for recursively nested template instantiations to N. The
+ default is 256.
+
+.. option:: -foperator-arrow-depth=N
+
+ Sets the limit for iterative calls to 'operator->' functions to N. The
+ default is 256.
+
+.. _objc:
+
+Objective-C Language Features
+=============================
+
+.. _objcxx:
+
+Objective-C++ Language Features
+===============================
+
+.. _openmp:
+
+OpenMP Features
+===============
+
+Clang supports all OpenMP 3.1 directives and clauses. In addition, some
+features of OpenMP 4.0 are supported. For example, ``#pragma omp simd``,
+``#pragma omp for simd``, ``#pragma omp parallel for simd`` directives, extended
+set of atomic constructs, ``proc_bind`` clause for all parallel-based
+directives, ``depend`` clause for ``#pragma omp task`` directive (except for
+array sections), ``#pragma omp cancel`` and ``#pragma omp cancellation point``
+directives, and ``#pragma omp taskgroup`` directive.
+
+Use `-fopenmp` to enable OpenMP. Support for OpenMP can be disabled with
+`-fno-openmp`.
+
+Controlling implementation limits
+---------------------------------
+
+.. option:: -fopenmp-use-tls
+
+ Controls code generation for OpenMP threadprivate variables. In presence of
+ this option all threadprivate variables are generated the same way as thread
+ local variables, using TLS support. If `-fno-openmp-use-tls`
+ is provided or target does not support TLS, code generation for threadprivate
+ variables relies on OpenMP runtime library.
+
+.. _opencl:
+
+OpenCL Features
+===============
+
+Clang can be used to compile OpenCL kernels for execution on a device
+(e.g. GPU). It is possible to compile the kernel into a binary (e.g. for AMD or
+Nvidia targets) that can be uploaded to run directly on a device (e.g. using
+`clCreateProgramWithBinary
+<https://www.khronos.org/registry/OpenCL/specs/opencl-1.1.pdf#111>`_) or
+into generic bitcode files loadable into other toolchains.
+
+Compiling to a binary using the default target from the installation can be done
+as follows:
+
+ .. code-block:: console
+
+ $ echo "kernel void k(){}" > test.cl
+ $ clang test.cl
+
+Compiling for a specific target can be done by specifying the triple corresponding
+to the target, for example:
+
+ .. code-block:: console
+
+ $ clang -target nvptx64-unknown-unknown test.cl
+ $ clang -target amdgcn-amd-amdhsa-opencl test.cl
+
+Compiling to bitcode can be done as follows:
+
+ .. code-block:: console
+
+ $ clang -c -emit-llvm test.cl
+
+This will produce a generic test.bc file that can be used in vendor toolchains
+to perform machine code generation.
+
+Clang currently supports OpenCL C language standards up to v2.0.
+
+OpenCL Specific Options
+-----------------------
+
+Most of the OpenCL build options from `the specification v2.0 section 5.8.4
+<https://www.khronos.org/registry/cl/specs/opencl-2.0.pdf#200>`_ are available.
+
+Examples:
+
+ .. code-block:: console
+
+ $ clang -cl-std=CL2.0 -cl-single-precision-constant test.cl
+
+Some extra options are available to support special OpenCL features.
+
+.. option:: -finclude-default-header
+
+Loads standard includes during compilations. By default OpenCL headers are not
+loaded and therefore standard library includes are not available. To load them
+automatically a flag has been added to the frontend (see also :ref:`the section
+on the OpenCL Header <opencl_header>`):
+
+ .. code-block:: console
+
+ $ clang -Xclang -finclude-default-header test.cl
+
+Alternatively ``-include`` or ``-I`` followed by the path to the header location
+can be given manually.
+
+ .. code-block:: console
+
+ $ clang -I<path to clang>/lib/Headers/opencl-c.h test.cl
+
+In this case the kernel code should contain ``#include <opencl-c.h>`` just as a
+regular C include.
+
+.. _opencl_cl_ext:
+
+.. option:: -cl-ext
+
+Disables support of OpenCL extensions. All OpenCL targets provide a list
+of extensions that they support. Clang allows to amend this using the ``-cl-ext``
+flag with a comma-separated list of extensions prefixed with ``'+'`` or ``'-'``.
+The syntax: ``-cl-ext=<(['-'|'+']<extension>[,])+>``, where extensions
+can be either one of `the OpenCL specification extensions
+<https://www.khronos.org/registry/cl/sdk/2.0/docs/man/xhtml/EXTENSION.html>`_
+or any known vendor extension. Alternatively, ``'all'`` can be used to enable
+or disable all known extensions.
+Example disabling double support for the 64-bit SPIR target:
+
+ .. code-block:: console
+
+ $ clang -cc1 -triple spir64-unknown-unknown -cl-ext=-cl_khr_fp64 test.cl
+
+Enabling all extensions except double support in R600 AMD GPU can be done using:
+
+ .. code-block:: console
+
+ $ clang -cc1 -triple r600-unknown-unknown -cl-ext=-all,+cl_khr_fp16 test.cl
+
+.. _opencl_fake_address_space_map:
+
+.. option:: -ffake-address-space-map
+
+Overrides the target address space map with a fake map.
+This allows adding explicit address space IDs to the bitcode for non-segmented
+memory architectures that don't have separate IDs for each of the OpenCL
+logical address spaces by default. Passing ``-ffake-address-space-map`` will
+add/override address spaces of the target compiled for with the following values:
+``1-global``, ``2-constant``, ``3-local``, ``4-generic``. The private address
+space is represented by the absence of an address space attribute in the IR (see
+also :ref:`the section on the address space attribute <opencl_addrsp>`).
+
+ .. code-block:: console
+
+ $ clang -ffake-address-space-map test.cl
+
+Some other flags used for the compilation for C can also be passed while
+compiling for OpenCL, examples: ``-c``, ``-O<1-4|s>``, ``-o``, ``-emit-llvm``, etc.
+
+OpenCL Targets
+--------------
+
+OpenCL targets are derived from the regular Clang target classes. The OpenCL
+specific parts of the target representation provide address space mapping as
+well as a set of supported extensions.
+
+Specific Targets
+^^^^^^^^^^^^^^^^
+
+There is a set of concrete HW architectures that OpenCL can be compiled for.
+
+- For AMD target:
+
+ .. code-block:: console
+
+ $ clang -target amdgcn-amd-amdhsa-opencl test.cl
+
+- For Nvidia architectures:
+
+ .. code-block:: console
+
+ $ clang -target nvptx64-unknown-unknown test.cl
+
+
+Generic Targets
+^^^^^^^^^^^^^^^
+
+- SPIR is available as a generic target to allow portable bitcode to be produced
+ that can be used across GPU toolchains. The implementation follows `the SPIR
+ specification <https://www.khronos.org/spir>`_. There are two flavors
+ available for 32 and 64 bits.
+
+ .. code-block:: console
+
+ $ clang -target spir-unknown-unknown test.cl
+ $ clang -target spir64-unknown-unknown test.cl
+
+ All known OpenCL extensions are supported in the SPIR targets. Clang will
+ generate SPIR v1.2 compatible IR for OpenCL versions up to 2.0 and SPIR v2.0
+ for OpenCL v2.0.
+
+- x86 is used by some implementations that are x86 compatible and currently
+ remains for backwards compatibility (with older implementations prior to
+ SPIR target support). For "non-SPMD" targets which cannot spawn multiple
+ work-items on the fly using hardware, which covers practically all non-GPU
+ devices such as CPUs and DSPs, additional processing is needed for the kernels
+ to support multiple work-item execution. For this, a 3rd party toolchain,
+ such as for example `POCL <http://portablecl.org/>`_, can be used.
+
+ This target does not support multiple memory segments and, therefore, the fake
+ address space map can be added using the :ref:`-ffake-address-space-map
+ <opencl_fake_address_space_map>` flag.
+
+.. _opencl_header:
+
+OpenCL Header
+-------------
+
+By default Clang will not include standard headers and therefore OpenCL builtin
+functions and some types (i.e. vectors) are unknown. The default CL header is,
+however, provided in the Clang installation and can be enabled by passing the
+``-finclude-default-header`` flag to the Clang frontend.
+
+ .. code-block:: console
+
+ $ echo "bool is_wg_uniform(int i){return get_enqueued_local_size(i)==get_local_size(i);}" > test.cl
+ $ clang -Xclang -finclude-default-header -cl-std=CL2.0 test.cl
+
+Because the header is very large and long to parse, PCH (:doc:`PCHInternals`)
+and modules (:doc:`Modules`) are used internally to improve the compilation
+speed.
+
+To enable modules for OpenCL:
+
+ .. code-block:: console
+
+ $ clang -target spir-unknown-unknown -c -emit-llvm -Xclang -finclude-default-header -fmodules -fimplicit-module-maps -fmodules-cache-path=<path to the generated module> test.cl
+
+OpenCL Extensions
+-----------------
+
+All of the ``cl_khr_*`` extensions from `the official OpenCL specification
+<https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/EXTENSION.html>`_
+up to and including version 2.0 are available and set per target depending on the
+support available in the specific architecture.
+
+It is possible to alter the default extensions setting per target using
+``-cl-ext`` flag. (See :ref:`flags description <opencl_cl_ext>` for more details).
+
+Vendor extensions can be added flexibly by declaring the list of types and
+functions associated with each extensions enclosed within the following
+compiler pragma directives:
+
+ .. code-block:: c
+
+ #pragma OPENCL EXTENSION the_new_extension_name : begin
+ // declare types and functions associated with the extension here
+ #pragma OPENCL EXTENSION the_new_extension_name : end
+
+For example, parsing the following code adds ``my_t`` type and ``my_func``
+function to the custom ``my_ext`` extension.
+
+ .. code-block:: c
+
+ #pragma OPENCL EXTENSION my_ext : begin
+ typedef struct{
+ int a;
+ }my_t;
+ void my_func(my_t);
+ #pragma OPENCL EXTENSION my_ext : end
+
+Declaring the same types in different vendor extensions is disallowed.
+
+OpenCL Metadata
+---------------
+
+Clang uses metadata to provide additional OpenCL semantics in IR needed for
+backends and OpenCL runtime.
+
+Each kernel will have function metadata attached to it, specifying the arguments.
+Kernel argument metadata is used to provide source level information for querying
+at runtime, for example using the `clGetKernelArgInfo
+<https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf#167>`_
+call.
+
+Note that ``-cl-kernel-arg-info`` enables more information about the original CL
+code to be added e.g. kernel parameter names will appear in the OpenCL metadata
+along with other information.
+
+The IDs used to encode the OpenCL's logical address spaces in the argument info
+metadata follows the SPIR address space mapping as defined in the SPIR
+specification `section 2.2
+<https://www.khronos.org/registry/spir/specs/spir_spec-2.0.pdf#18>`_
+
+OpenCL-Specific Attributes
+--------------------------
+
+OpenCL support in Clang contains a set of attribute taken directly from the
+specification as well as additional attributes.
+
+See also :doc:`AttributeReference`.
+
+nosvm
+^^^^^
+
+Clang supports this attribute to comply to OpenCL v2.0 conformance, but it
+does not have any effect on the IR. For more details reffer to the specification
+`section 6.7.2
+<https://www.khronos.org/registry/cl/specs/opencl-2.0-openclc.pdf#49>`_
+
+
+opencl_unroll_hint
+^^^^^^^^^^^^^^^^^^
+
+The implementation of this feature mirrors the unroll hint for C.
+More details on the syntax can be found in the specification
+`section 6.11.5
+<https://www.khronos.org/registry/cl/specs/opencl-2.0-openclc.pdf#61>`_
+
+convergent
+^^^^^^^^^^
+
+To make sure no invalid optimizations occur for single program multiple data
+(SPMD) / single instruction multiple thread (SIMT) Clang provides attributes that
+can be used for special functions that have cross work item semantics.
+An example is the subgroup operations such as `intel_sub_group_shuffle
+<https://www.khronos.org/registry/cl/extensions/intel/cl_intel_subgroups.txt>`_
+
+ .. code-block:: c
+
+ // Define custom my_sub_group_shuffle(data, c)
+ // that makes use of intel_sub_group_shuffle
+ r1 = ...
+ if (r0) r1 = computeA();
+ // Shuffle data from r1 into r3
+ // of threads id r2.
+ r3 = my_sub_group_shuffle(r1, r2);
+ if (r0) r3 = computeB();
+
+with non-SPMD semantics this is optimized to the following equivalent code:
+
+ .. code-block:: c
+
+ r1 = ...
+ if (!r0)
+ // Incorrect functionality! The data in r1
+ // have not been computed by all threads yet.
+ r3 = my_sub_group_shuffle(r1, r2);
+ else {
+ r1 = computeA();
+ r3 = my_sub_group_shuffle(r1, r2);
+ r3 = computeB();
+ }
+
+Declaring the function ``my_sub_group_shuffle`` with the convergent attribute
+would prevent this:
+
+ .. code-block:: c
+
+ my_sub_group_shuffle() __attribute__((convergent));
+
+Using ``convergent`` guarantees correct execution by keeping CFG equivalence
+wrt operations marked as ``convergent``. CFG ``G´`` is equivalent to ``G`` wrt
+node ``Ni`` : ``iff â Nj (iâ j)`` domination and post-domination relations with
+respect to ``Ni`` remain the same in both ``G`` and ``G´``.
+
+noduplicate
+^^^^^^^^^^^
+
+``noduplicate`` is more restrictive with respect to optimizations than
+``convergent`` because a convergent function only preserves CFG equivalence.
+This allows some optimizations to happen as long as the control flow remains
+unmodified.
+
+ .. code-block:: c
+
+ for (int i=0; i<4; i++)
+ my_sub_group_shuffle()
+
+can be modified to:
+
+ .. code-block:: c
+
+ my_sub_group_shuffle();
+ my_sub_group_shuffle();
+ my_sub_group_shuffle();
+ my_sub_group_shuffle();
+
+while using ``noduplicate`` would disallow this. Also ``noduplicate`` doesn't
+have the same safe semantics of CFG as ``convergent`` and can cause changes in
+CFG that modify semantics of the original program.
+
+``noduplicate`` is kept for backwards compatibility only and it considered to be
+deprecated for future uses.
+
+.. _opencl_addrsp:
+
+address_space
+^^^^^^^^^^^^^
+
+Clang has arbitrary address space support using the ``address_space(N)``
+attribute, where ``N`` is an integer number in the range ``0`` to ``16777215``
+(``0xffffffu``).
+
+An OpenCL implementation provides a list of standard address spaces using
+keywords: ``private``, ``local``, ``global``, and ``generic``. In the AST and
+in the IR local, global, or generic will be represented by the address space
+attribute with the corresponding unique number. Note that private does not have
+any corresponding attribute added and, therefore, is represented by the absence
+of an address space number. The specific IDs for an address space do not have to
+match between the AST and the IR. Typically in the AST address space numbers
+represent logical segments while in the IR they represent physical segments.
+Therefore, machines with flat memory segments can map all AST address space
+numbers to the same physical segment ID or skip address space attribute
+completely while generating the IR. However, if the address space information
+is needed by the IR passes e.g. to improve alias analysis, it is recommended
+to keep it and only lower to reflect physical memory segments in the late
+machine passes.
+
+OpenCL builtins
+---------------
+
+There are some standard OpenCL functions that are implemented as Clang builtins:
+
+- All pipe functions from `section 6.13.16.2/6.13.16.3
+ <https://www.khronos.org/registry/cl/specs/opencl-2.0-openclc.pdf#160>`_ of
+ the OpenCL v2.0 kernel language specification. `
+
+- Address space qualifier conversion functions ``to_global``/``to_local``/``to_private``
+ from `section 6.13.9
+ <https://www.khronos.org/registry/cl/specs/opencl-2.0-openclc.pdf#101>`_.
+
+- All the ``enqueue_kernel`` functions from `section 6.13.17.1
+ <https://www.khronos.org/registry/cl/specs/opencl-2.0-openclc.pdf#164>`_ and
+ enqueue query functions from `section 6.13.17.5
+ <https://www.khronos.org/registry/cl/specs/opencl-2.0-openclc.pdf#171>`_.
+
+.. _target_features:
+
+Target-Specific Features and Limitations
+========================================
+
+CPU Architectures Features and Limitations
+------------------------------------------
+
+X86
+^^^
+
+The support for X86 (both 32-bit and 64-bit) is considered stable on
+Darwin (Mac OS X), Linux, FreeBSD, and Dragonfly BSD: it has been tested
+to correctly compile many large C, C++, Objective-C, and Objective-C++
+codebases.
+
+On ``x86_64-mingw32``, passing i128(by value) is incompatible with the
+Microsoft x64 calling convention. You might need to tweak
+``WinX86_64ABIInfo::classify()`` in lib/CodeGen/TargetInfo.cpp.
+
+For the X86 target, clang supports the `-m16` command line
+argument which enables 16-bit code output. This is broadly similar to
+using ``asm(".code16gcc")`` with the GNU toolchain. The generated code
+and the ABI remains 32-bit but the assembler emits instructions
+appropriate for a CPU running in 16-bit mode, with address-size and
+operand-size prefixes to enable 32-bit addressing and operations.
+
+ARM
+^^^
+
+The support for ARM (specifically ARMv6 and ARMv7) is considered stable
+on Darwin (iOS): it has been tested to correctly compile many large C,
+C++, Objective-C, and Objective-C++ codebases. Clang only supports a
+limited number of ARM architectures. It does not yet fully support
+ARMv5, for example.
+
+PowerPC
+^^^^^^^
+
+The support for PowerPC (especially PowerPC64) is considered stable
+on Linux and FreeBSD: it has been tested to correctly compile many
+large C and C++ codebases. PowerPC (32bit) is still missing certain
+features (e.g. PIC code on ELF platforms).
+
+Other platforms
+^^^^^^^^^^^^^^^
+
+clang currently contains some support for other architectures (e.g. Sparc);
+however, significant pieces of code generation are still missing, and they
+haven't undergone significant testing.
+
+clang contains limited support for the MSP430 embedded processor, but
+both the clang support and the LLVM backend support are highly
+experimental.
+
+Other platforms are completely unsupported at the moment. Adding the
+minimal support needed for parsing and semantic analysis on a new
+platform is quite easy; see ``lib/Basic/Targets.cpp`` in the clang source
+tree. This level of support is also sufficient for conversion to LLVM IR
+for simple programs. Proper support for conversion to LLVM IR requires
+adding code to ``lib/CodeGen/CGCall.cpp`` at the moment; this is likely to
+change soon, though. Generating assembly requires a suitable LLVM
+backend.
+
+Operating System Features and Limitations
+-----------------------------------------
+
+Darwin (Mac OS X)
+^^^^^^^^^^^^^^^^^
+
+Thread Sanitizer is not supported.
+
+Windows
+^^^^^^^
+
+Clang has experimental support for targeting "Cygming" (Cygwin / MinGW)
+platforms.
+
+See also :ref:`Microsoft Extensions <c_ms>`.
+
+Cygwin
+""""""
+
+Clang works on Cygwin-1.7.
+
+MinGW32
+"""""""
+
+Clang works on some mingw32 distributions. Clang assumes directories as
+below;
+
+- ``C:/mingw/include``
+- ``C:/mingw/lib``
+- ``C:/mingw/lib/gcc/mingw32/4.[3-5].0/include/c++``
+
+On MSYS, a few tests might fail.
+
+MinGW-w64
+"""""""""
+
+For 32-bit (i686-w64-mingw32), and 64-bit (x86\_64-w64-mingw32), Clang
+assumes as below;
+
+- ``GCC versions 4.5.0 to 4.5.3, 4.6.0 to 4.6.2, or 4.7.0 (for the C++ header search path)``
+- ``some_directory/bin/gcc.exe``
+- ``some_directory/bin/clang.exe``
+- ``some_directory/bin/clang++.exe``
+- ``some_directory/bin/../include/c++/GCC_version``
+- ``some_directory/bin/../include/c++/GCC_version/x86_64-w64-mingw32``
+- ``some_directory/bin/../include/c++/GCC_version/i686-w64-mingw32``
+- ``some_directory/bin/../include/c++/GCC_version/backward``
+- ``some_directory/bin/../x86_64-w64-mingw32/include``
+- ``some_directory/bin/../i686-w64-mingw32/include``
+- ``some_directory/bin/../include``
+
+This directory layout is standard for any toolchain you will find on the
+official `MinGW-w64 website <http://mingw-w64.sourceforge.net>`_.
+
+Clang expects the GCC executable "gcc.exe" compiled for
+``i686-w64-mingw32`` (or ``x86_64-w64-mingw32``) to be present on PATH.
+
+`Some tests might fail <https://bugs.llvm.org/show_bug.cgi?id=9072>`_ on
+``x86_64-w64-mingw32``.
+
+.. _clang-cl:
+
+clang-cl
+========
+
+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. `vcvars32.bat <http://msdn.microsoft.com/en-us/library/f2ccy3wt.aspx>`_.
+
+clang-cl can also be used from inside Visual Studio by using an LLVM Platform
+Toolset.
+
+Command-Line Options
+--------------------
+
+To be compatible with cl.exe, clang-cl supports most of the same command-line
+options. Those options can start with either ``/`` or ``-``. It also supports
+some of Clang's core options, such as the ``-W`` options.
+
+Options that are known to clang-cl, but not currently supported, are ignored
+with a warning. For example:
+
+ ::
+
+ clang-cl.exe: warning: argument unused during compilation: '/AI'
+
+To suppress warnings about unused arguments, use the ``-Qunused-arguments`` option.
+
+Options that are not known to clang-cl will be ignored by default. Use the
+``-Werror=unknown-argument`` option in order to treat them as errors. If these
+options are spelled with a leading ``/``, they will be mistaken for a filename:
+
+ ::
+
+ clang-cl.exe: error: no such file or directory: '/foobar'
+
+Please `file a bug <https://bugs.llvm.org/enter_bug.cgi?product=clang&component=Driver>`_
+for any valid cl.exe flags that clang-cl does not understand.
+
+Execute ``clang-cl /?`` to see a list of supported options:
+
+ ::
+
+ CL.EXE COMPATIBILITY OPTIONS:
+ /? Display available options
+ /arch:<value> Set architecture for code generation
+ /Brepro- Emit an object file which cannot be reproduced over time
+ /Brepro Emit an object file which can be reproduced over time
+ /C Don't discard comments when preprocessing
+ /c Compile only
+ /d1reportAllClassLayout Dump record layout information
+ /diagnostics:caret Enable caret and column diagnostics (on by default)
+ /diagnostics:classic Disable column and caret diagnostics
+ /diagnostics:column Disable caret diagnostics but keep column info
+ /D <macro[=value]> Define macro
+ /EH<value> Exception handling model
+ /EP Disable linemarker output and preprocess to stdout
+ /execution-charset:<value>
+ Runtime encoding, supports only UTF-8
+ /E Preprocess to stdout
+ /fallback Fall back to cl.exe if clang-cl fails to compile
+ /FA Output assembly code file during compilation
+ /Fa<file or directory> Output assembly code to this file during compilation (with /FA)
+ /Fe<file or directory> Set output executable file or directory (ends in / or \)
+ /FI <value> Include file before parsing
+ /Fi<file> Set preprocess output file name (with /P)
+ /Fo<file or directory> Set output object file, or directory (ends in / or \) (with /c)
+ /fp:except-
+ /fp:except
+ /fp:fast
+ /fp:precise
+ /fp:strict
+ /Fp<filename> Set pch filename (with /Yc and /Yu)
+ /GA Assume thread-local variables are defined in the executable
+ /Gd Set __cdecl as a default calling convention
+ /GF- Disable string pooling
+ /GR- Disable emission of RTTI data
+ /GR Enable emission of RTTI data
+ /Gr Set __fastcall as a default calling convention
+ /GS- Disable buffer security check
+ /GS Enable buffer security check
+ /Gs<value> Set stack probe size
+ /Gv Set __vectorcall as a default calling convention
+ /Gw- Don't put each data item in its own section
+ /Gw Put each data item in its own section
+ /GX- Enable exception handling
+ /GX Enable exception handling
+ /Gy- Don't put each function in its own section
+ /Gy Put each function in its own section
+ /Gz Set __stdcall as a default calling convention
+ /help Display available options
+ /imsvc <dir> Add directory to system include search path, as if part of %INCLUDE%
+ /I <dir> Add directory to include search path
+ /J Make char type unsigned
+ /LDd Create debug DLL
+ /LD Create DLL
+ /link <options> Forward options to the linker
+ /MDd Use DLL debug run-time
+ /MD Use DLL run-time
+ /MTd Use static debug run-time
+ /MT Use static run-time
+ /Od Disable optimization
+ /Oi- Disable use of builtin functions
+ /Oi Enable use of builtin functions
+ /Os Optimize for size
+ /Ot Optimize for speed
+ /O<value> Optimization level
+ /o <file or directory> Set output file or directory (ends in / or \)
+ /P Preprocess to file
+ /Qvec- Disable the loop vectorization passes
+ /Qvec Enable the loop vectorization passes
+ /showIncludes Print info about included files to stderr
+ /source-charset:<value> Source encoding, supports only UTF-8
+ /std:<value> Language standard to compile for
+ /TC Treat all source files as C
+ /Tc <filename> Specify a C source file
+ /TP Treat all source files as C++
+ /Tp <filename> Specify a C++ source file
+ /utf-8 Set source and runtime encoding to UTF-8 (default)
+ /U <macro> Undefine macro
+ /vd<value> Control vtordisp placement
+ /vmb Use a best-case representation method for member pointers
+ /vmg Use a most-general representation for member pointers
+ /vmm Set the default most-general representation to multiple inheritance
+ /vms Set the default most-general representation to single inheritance
+ /vmv Set the default most-general representation to virtual inheritance
+ /volatile:iso Volatile loads and stores have standard semantics
+ /volatile:ms Volatile loads and stores have acquire and release semantics
+ /W0 Disable all warnings
+ /W1 Enable -Wall
+ /W2 Enable -Wall
+ /W3 Enable -Wall
+ /W4 Enable -Wall and -Wextra
+ /Wall Enable -Wall and -Wextra
+ /WX- Do not treat warnings as errors
+ /WX Treat warnings as errors
+ /w Disable all warnings
+ /Y- Disable precompiled headers, overrides /Yc and /Yu
+ /Yc<filename> Generate a pch file for all code up to and including <filename>
+ /Yu<filename> Load a pch file and use it instead of all code up to and including <filename>
+ /Z7 Enable CodeView debug information in object files
+ /Zc:sizedDealloc- Disable C++14 sized global deallocation functions
+ /Zc:sizedDealloc Enable C++14 sized global deallocation functions
+ /Zc:strictStrings Treat string literals as const
+ /Zc:threadSafeInit- Disable thread-safe initialization of static variables
+ /Zc:threadSafeInit Enable thread-safe initialization of static variables
+ /Zc:trigraphs- Disable trigraphs (default)
+ /Zc:trigraphs Enable trigraphs
+ /Zc:twoPhase- Disable two-phase name lookup in templates
+ /Zc:twoPhase Enable two-phase name lookup in templates
+ /Zd Emit debug line number tables only
+ /Zi Alias for /Z7. Does not produce PDBs.
+ /Zl Don't mention any default libraries in the object file
+ /Zp Set the default maximum struct packing alignment to 1
+ /Zp<value> Specify the default maximum struct packing alignment
+ /Zs Syntax-check only
+
+ OPTIONS:
+ -### Print (but do not run) the commands to run for this compilation
+ --analyze Run the static analyzer
+ -fansi-escape-codes Use ANSI escape codes for diagnostics
+ -fcolor-diagnostics Use colors in diagnostics
+ -fdebug-macro Emit macro debug information
+ -fdelayed-template-parsing
+ Parse templated function definitions at the end of the translation unit
+ -fdiagnostics-absolute-paths
+ Print absolute paths in diagnostics
+ -fdiagnostics-parseable-fixits
+ Print fix-its in machine parseable form
+ -flto=<value> Set LTO mode to either 'full' or 'thin'
+ -flto Enable LTO in 'full' mode
+ -fms-compatibility-version=<value>
+ Dot-separated value representing the Microsoft compiler version
+ number to report in _MSC_VER (0 = don't define it (default))
+ -fms-compatibility Enable full Microsoft Visual C++ compatibility
+ -fms-extensions Accept some non-standard constructs supported by the Microsoft compiler
+ -fmsc-version=<value> Microsoft compiler version number to report in _MSC_VER
+ (0 = don't define it (default))
+ -fno-debug-macro Do not emit macro debug information
+ -fno-delayed-template-parsing
+ Disable delayed template parsing
+ -fno-sanitize-address-use-after-scope
+ Disable use-after-scope detection in AddressSanitizer
+ -fno-sanitize-blacklist Don't use blacklist file for sanitizers
+ -fno-sanitize-cfi-cross-dso
+ Disable control flow integrity (CFI) checks for cross-DSO calls.
+ -fno-sanitize-coverage=<value>
+ Disable specified features of coverage instrumentation for Sanitizers
+ -fno-sanitize-memory-track-origins
+ Disable origins tracking in MemorySanitizer
+ -fno-sanitize-recover=<value>
+ Disable recovery for specified sanitizers
+ -fno-sanitize-stats Disable sanitizer statistics gathering.
+ -fno-sanitize-thread-atomics
+ Disable atomic operations instrumentation in ThreadSanitizer
+ -fno-sanitize-thread-func-entry-exit
+ Disable function entry/exit instrumentation in ThreadSanitizer
+ -fno-sanitize-thread-memory-access
+ Disable memory access instrumentation in ThreadSanitizer
+ -fno-sanitize-trap=<value>
+ Disable trapping for specified sanitizers
+ -fno-standalone-debug Limit debug information produced to reduce size of debug binary
+ -fprofile-instr-generate=<file>
+ Generate instrumented code to collect execution counts into <file>
+ (overridden by LLVM_PROFILE_FILE env var)
+ -fprofile-instr-generate
+ Generate instrumented code to collect execution counts into default.profraw file
+ (overridden by '=' form of option or LLVM_PROFILE_FILE env var)
+ -fprofile-instr-use=<value>
+ Use instrumentation data for profile-guided optimization
+ -fsanitize-address-field-padding=<value>
+ Level of field padding for AddressSanitizer
+ -fsanitize-address-globals-dead-stripping
+ Enable linker dead stripping of globals in AddressSanitizer
+ -fsanitize-address-use-after-scope
+ Enable use-after-scope detection in AddressSanitizer
+ -fsanitize-blacklist=<value>
+ Path to blacklist file for sanitizers
+ -fsanitize-cfi-cross-dso
+ Enable control flow integrity (CFI) checks for cross-DSO calls.
+ -fsanitize-coverage=<value>
+ Specify the type of coverage instrumentation for Sanitizers
+ -fsanitize-memory-track-origins=<value>
+ Enable origins tracking in MemorySanitizer
+ -fsanitize-memory-track-origins
+ Enable origins tracking in MemorySanitizer
+ -fsanitize-memory-use-after-dtor
+ Enable use-after-destroy detection in MemorySanitizer
+ -fsanitize-recover=<value>
+ Enable recovery for specified sanitizers
+ -fsanitize-stats Enable sanitizer statistics gathering.
+ -fsanitize-thread-atomics
+ Enable atomic operations instrumentation in ThreadSanitizer (default)
+ -fsanitize-thread-func-entry-exit
+ Enable function entry/exit instrumentation in ThreadSanitizer (default)
+ -fsanitize-thread-memory-access
+ Enable memory access instrumentation in ThreadSanitizer (default)
+ -fsanitize-trap=<value> Enable trapping for specified sanitizers
+ -fsanitize-undefined-strip-path-components=<number>
+ Strip (or keep only, if negative) a given number of path components when emitting check metadata.
+ -fsanitize=<check> Turn on runtime checks for various forms of undefined or suspicious
+ behavior. See user manual for available checks
+ -fstandalone-debug Emit full debug info for all types used by the program
+ -gcodeview Generate CodeView debug information
+ -gline-tables-only Emit debug line number tables only
+ -miamcu Use Intel MCU ABI
+ -mllvm <value> Additional arguments to forward to LLVM's option processing
+ -nobuiltininc Disable builtin #include directories
+ -Qunused-arguments Don't emit warning for unused driver arguments
+ -R<remark> Enable the specified remark
+ --target=<value> Generate code for the given target
+ -v Show commands to run and use verbose output
+ -W<warning> Enable the specified warning
+ -Xclang <arg> Pass <arg> to the clang compiler
+
+The /fallback Option
+^^^^^^^^^^^^^^^^^^^^
+
+When clang-cl is run with the ``/fallback`` option, it will first try to
+compile files itself. For any file that it fails to compile, it will fall back
+and try to compile the file by invoking cl.exe.
+
+This option is intended to be used as a temporary means to build projects where
+clang-cl cannot successfully compile all the files. clang-cl may fail to compile
+a file either because it cannot generate code for some C++ feature, or because
+it cannot parse some Microsoft language extension.
Added: www-releases/trunk/5.0.2/tools/clang/docs/_sources/index.txt
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_sources/index.txt?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_sources/index.txt (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_sources/index.txt Thu May 10 06:54:16 2018
@@ -0,0 +1,94 @@
+.. Clang documentation master file, created by
+ sphinx-quickstart on Sun Dec 9 20:01:55 2012.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+.. title:: Welcome to Clang's documentation!
+
+.. toctree::
+ :maxdepth: 1
+
+ ReleaseNotes
+
+Using Clang as a Compiler
+=========================
+
+.. toctree::
+ :maxdepth: 1
+
+ UsersManual
+ Toolchain
+ LanguageExtensions
+ ClangCommandLineReference
+ AttributeReference
+ DiagnosticsReference
+ CrossCompilation
+ ThreadSafetyAnalysis
+ AddressSanitizer
+ ThreadSanitizer
+ MemorySanitizer
+ UndefinedBehaviorSanitizer
+ DataFlowSanitizer
+ LeakSanitizer
+ SanitizerCoverage
+ SanitizerStats
+ SanitizerSpecialCaseList
+ ControlFlowIntegrity
+ LTOVisibility
+ SafeStack
+ SourceBasedCodeCoverage
+ Modules
+ MSVCCompatibility
+ ThinLTO
+ CommandGuide/index
+ FAQ
+
+Using Clang as a Library
+========================
+
+.. toctree::
+ :maxdepth: 1
+
+ Tooling
+ ExternalClangExamples
+ IntroductionToTheClangAST
+ LibTooling
+ LibFormat
+ ClangPlugins
+ RAVFrontendAction
+ LibASTMatchersTutorial
+ LibASTMatchers
+ HowToSetupToolingForLLVM
+ JSONCompilationDatabase
+
+Using Clang Tools
+=================
+
+.. toctree::
+ :maxdepth: 1
+
+ ClangTools
+ ClangCheck
+ ClangFormat
+ ClangFormatStyleOptions
+
+Design Documents
+================
+
+.. toctree::
+ :maxdepth: 1
+
+ InternalsManual
+ DriverInternals
+ PTHInternals
+ PCHInternals
+ ItaniumMangleAbiTags
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
+
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/ajax-loader.gif
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/ajax-loader.gif?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/ajax-loader.gif
------------------------------------------------------------------------------
svn:mime-type = image/gif
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/alert_info_32.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/alert_info_32.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/alert_info_32.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/alert_warning_32.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/alert_warning_32.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/alert_warning_32.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/basic.css
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/basic.css?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_static/basic.css (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_static/basic.css Thu May 10 06:54:16 2018
@@ -0,0 +1,540 @@
+/*
+ * basic.css
+ * ~~~~~~~~~
+ *
+ * Sphinx stylesheet -- basic theme.
+ *
+ * :copyright: Copyright 2007-2011 by the Sphinx team, see AUTHORS.
+ * :license: BSD, see LICENSE for details.
+ *
+ */
+
+/* -- main layout ----------------------------------------------------------- */
+
+div.clearer {
+ clear: both;
+}
+
+/* -- relbar ---------------------------------------------------------------- */
+
+div.related {
+ width: 100%;
+ font-size: 90%;
+}
+
+div.related h3 {
+ display: none;
+}
+
+div.related ul {
+ margin: 0;
+ padding: 0 0 0 10px;
+ list-style: none;
+}
+
+div.related li {
+ display: inline;
+}
+
+div.related li.right {
+ float: right;
+ margin-right: 5px;
+}
+
+/* -- sidebar --------------------------------------------------------------- */
+
+div.sphinxsidebarwrapper {
+ padding: 10px 5px 0 10px;
+}
+
+div.sphinxsidebar {
+ float: left;
+ width: 230px;
+ margin-left: -100%;
+ font-size: 90%;
+}
+
+div.sphinxsidebar ul {
+ list-style: none;
+}
+
+div.sphinxsidebar ul ul,
+div.sphinxsidebar ul.want-points {
+ margin-left: 20px;
+ list-style: square;
+}
+
+div.sphinxsidebar ul ul {
+ margin-top: 0;
+ margin-bottom: 0;
+}
+
+div.sphinxsidebar form {
+ margin-top: 10px;
+}
+
+div.sphinxsidebar input {
+ border: 1px solid #98dbcc;
+ font-family: sans-serif;
+ font-size: 1em;
+}
+
+div.sphinxsidebar #searchbox input[type="text"] {
+ width: 170px;
+}
+
+div.sphinxsidebar #searchbox input[type="submit"] {
+ width: 30px;
+}
+
+img {
+ border: 0;
+}
+
+/* -- search page ----------------------------------------------------------- */
+
+ul.search {
+ margin: 10px 0 0 20px;
+ padding: 0;
+}
+
+ul.search li {
+ padding: 5px 0 5px 20px;
+ background-image: url(file.png);
+ background-repeat: no-repeat;
+ background-position: 0 7px;
+}
+
+ul.search li a {
+ font-weight: bold;
+}
+
+ul.search li div.context {
+ color: #888;
+ margin: 2px 0 0 30px;
+ text-align: left;
+}
+
+ul.keywordmatches li.goodmatch a {
+ font-weight: bold;
+}
+
+/* -- index page ------------------------------------------------------------ */
+
+table.contentstable {
+ width: 90%;
+}
+
+table.contentstable p.biglink {
+ line-height: 150%;
+}
+
+a.biglink {
+ font-size: 1.3em;
+}
+
+span.linkdescr {
+ font-style: italic;
+ padding-top: 5px;
+ font-size: 90%;
+}
+
+/* -- general index --------------------------------------------------------- */
+
+table.indextable {
+ width: 100%;
+}
+
+table.indextable td {
+ text-align: left;
+ vertical-align: top;
+}
+
+table.indextable dl, table.indextable dd {
+ margin-top: 0;
+ margin-bottom: 0;
+}
+
+table.indextable tr.pcap {
+ height: 10px;
+}
+
+table.indextable tr.cap {
+ margin-top: 10px;
+ background-color: #f2f2f2;
+}
+
+img.toggler {
+ margin-right: 3px;
+ margin-top: 3px;
+ cursor: pointer;
+}
+
+div.modindex-jumpbox {
+ border-top: 1px solid #ddd;
+ border-bottom: 1px solid #ddd;
+ margin: 1em 0 1em 0;
+ padding: 0.4em;
+}
+
+div.genindex-jumpbox {
+ border-top: 1px solid #ddd;
+ border-bottom: 1px solid #ddd;
+ margin: 1em 0 1em 0;
+ padding: 0.4em;
+}
+
+/* -- general body styles --------------------------------------------------- */
+
+a.headerlink {
+ visibility: hidden;
+}
+
+h1:hover > a.headerlink,
+h2:hover > a.headerlink,
+h3:hover > a.headerlink,
+h4:hover > a.headerlink,
+h5:hover > a.headerlink,
+h6:hover > a.headerlink,
+dt:hover > a.headerlink {
+ visibility: visible;
+}
+
+div.body p.caption {
+ text-align: inherit;
+}
+
+div.body td {
+ text-align: left;
+}
+
+.field-list ul {
+ padding-left: 1em;
+}
+
+.first {
+ margin-top: 0 !important;
+}
+
+p.rubric {
+ margin-top: 30px;
+ font-weight: bold;
+}
+
+img.align-left, .figure.align-left, object.align-left {
+ clear: left;
+ float: left;
+ margin-right: 1em;
+}
+
+img.align-right, .figure.align-right, object.align-right {
+ clear: right;
+ float: right;
+ margin-left: 1em;
+}
+
+img.align-center, .figure.align-center, object.align-center {
+ display: block;
+ margin-left: auto;
+ margin-right: auto;
+}
+
+.align-left {
+ text-align: left;
+}
+
+.align-center {
+ text-align: center;
+}
+
+.align-right {
+ text-align: right;
+}
+
+/* -- sidebars -------------------------------------------------------------- */
+
+div.sidebar {
+ margin: 0 0 0.5em 1em;
+ border: 1px solid #ddb;
+ padding: 7px 7px 0 7px;
+ background-color: #ffe;
+ width: 40%;
+ float: right;
+}
+
+p.sidebar-title {
+ font-weight: bold;
+}
+
+/* -- topics ---------------------------------------------------------------- */
+
+div.topic {
+ border: 1px solid #ccc;
+ padding: 7px 7px 0 7px;
+ margin: 10px 0 10px 0;
+}
+
+p.topic-title {
+ font-size: 1.1em;
+ font-weight: bold;
+ margin-top: 10px;
+}
+
+/* -- admonitions ----------------------------------------------------------- */
+
+div.admonition {
+ margin-top: 10px;
+ margin-bottom: 10px;
+ padding: 7px;
+}
+
+div.admonition dt {
+ font-weight: bold;
+}
+
+div.admonition dl {
+ margin-bottom: 0;
+}
+
+p.admonition-title {
+ margin: 0px 10px 5px 0px;
+ font-weight: bold;
+}
+
+div.body p.centered {
+ text-align: center;
+ margin-top: 25px;
+}
+
+/* -- tables ---------------------------------------------------------------- */
+
+table.docutils {
+ border: 0;
+ border-collapse: collapse;
+}
+
+table.docutils td, table.docutils th {
+ padding: 1px 8px 1px 5px;
+ border-top: 0;
+ border-left: 0;
+ border-right: 0;
+ border-bottom: 1px solid #aaa;
+}
+
+table.field-list td, table.field-list th {
+ border: 0 !important;
+}
+
+table.footnote td, table.footnote th {
+ border: 0 !important;
+}
+
+th {
+ text-align: left;
+ padding-right: 5px;
+}
+
+table.citation {
+ border-left: solid 1px gray;
+ margin-left: 1px;
+}
+
+table.citation td {
+ border-bottom: none;
+}
+
+/* -- other body styles ----------------------------------------------------- */
+
+ol.arabic {
+ list-style: decimal;
+}
+
+ol.loweralpha {
+ list-style: lower-alpha;
+}
+
+ol.upperalpha {
+ list-style: upper-alpha;
+}
+
+ol.lowerroman {
+ list-style: lower-roman;
+}
+
+ol.upperroman {
+ list-style: upper-roman;
+}
+
+dl {
+ margin-bottom: 15px;
+}
+
+dd p {
+ margin-top: 0px;
+}
+
+dd ul, dd table {
+ margin-bottom: 10px;
+}
+
+dd {
+ margin-top: 3px;
+ margin-bottom: 10px;
+ margin-left: 30px;
+}
+
+dt:target, .highlighted {
+ background-color: #fbe54e;
+}
+
+dl.glossary dt {
+ font-weight: bold;
+ font-size: 1.1em;
+}
+
+.field-list ul {
+ margin: 0;
+ padding-left: 1em;
+}
+
+.field-list p {
+ margin: 0;
+}
+
+.refcount {
+ color: #060;
+}
+
+.optional {
+ font-size: 1.3em;
+}
+
+.versionmodified {
+ font-style: italic;
+}
+
+.system-message {
+ background-color: #fda;
+ padding: 5px;
+ border: 3px solid red;
+}
+
+.footnote:target {
+ background-color: #ffa;
+}
+
+.line-block {
+ display: block;
+ margin-top: 1em;
+ margin-bottom: 1em;
+}
+
+.line-block .line-block {
+ margin-top: 0;
+ margin-bottom: 0;
+ margin-left: 1.5em;
+}
+
+.guilabel, .menuselection {
+ font-family: sans-serif;
+}
+
+.accelerator {
+ text-decoration: underline;
+}
+
+.classifier {
+ font-style: oblique;
+}
+
+abbr, acronym {
+ border-bottom: dotted 1px;
+ cursor: help;
+}
+
+/* -- code displays --------------------------------------------------------- */
+
+pre {
+ overflow: auto;
+ overflow-y: hidden; /* fixes display issues on Chrome browsers */
+}
+
+td.linenos pre {
+ padding: 5px 0px;
+ border: 0;
+ background-color: transparent;
+ color: #aaa;
+}
+
+table.highlighttable {
+ margin-left: 0.5em;
+}
+
+table.highlighttable td {
+ padding: 0 0.5em 0 0.5em;
+}
+
+tt.descname {
+ background-color: transparent;
+ font-weight: bold;
+ font-size: 1.2em;
+}
+
+tt.descclassname {
+ background-color: transparent;
+}
+
+tt.xref, a tt {
+ background-color: transparent;
+ font-weight: bold;
+}
+
+h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
+ background-color: transparent;
+}
+
+.viewcode-link {
+ float: right;
+}
+
+.viewcode-back {
+ float: right;
+ font-family: sans-serif;
+}
+
+div.viewcode-block:target {
+ margin: -1px -10px;
+ padding: 0 10px;
+}
+
+/* -- math display ---------------------------------------------------------- */
+
+img.math {
+ vertical-align: middle;
+}
+
+div.body div.math p {
+ text-align: center;
+}
+
+span.eqno {
+ float: right;
+}
+
+/* -- printout stylesheet --------------------------------------------------- */
+
+ at media print {
+ div.document,
+ div.documentwrapper,
+ div.bodywrapper {
+ margin: 0 !important;
+ width: 100%;
+ }
+
+ div.sphinxsidebar,
+ div.related,
+ div.footer,
+ #top-link {
+ display: none;
+ }
+}
\ No newline at end of file
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/bg-page.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/bg-page.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/bg-page.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/bullet_orange.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/bullet_orange.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/bullet_orange.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/comment-bright.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/comment-bright.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/comment-bright.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/comment-close.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/comment-close.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/comment-close.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/comment.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/comment.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/comment.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/doctools.js
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/doctools.js?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_static/doctools.js (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_static/doctools.js Thu May 10 06:54:16 2018
@@ -0,0 +1,247 @@
+/*
+ * doctools.js
+ * ~~~~~~~~~~~
+ *
+ * Sphinx JavaScript utilities for all documentation.
+ *
+ * :copyright: Copyright 2007-2011 by the Sphinx team, see AUTHORS.
+ * :license: BSD, see LICENSE for details.
+ *
+ */
+
+/**
+ * select a different prefix for underscore
+ */
+$u = _.noConflict();
+
+/**
+ * make the code below compatible with browsers without
+ * an installed firebug like debugger
+if (!window.console || !console.firebug) {
+ var names = ["log", "debug", "info", "warn", "error", "assert", "dir",
+ "dirxml", "group", "groupEnd", "time", "timeEnd", "count", "trace",
+ "profile", "profileEnd"];
+ window.console = {};
+ for (var i = 0; i < names.length; ++i)
+ window.console[names[i]] = function() {};
+}
+ */
+
+/**
+ * small helper function to urldecode strings
+ */
+jQuery.urldecode = function(x) {
+ return decodeURIComponent(x).replace(/\+/g, ' ');
+}
+
+/**
+ * small helper function to urlencode strings
+ */
+jQuery.urlencode = encodeURIComponent;
+
+/**
+ * This function returns the parsed url parameters of the
+ * current request. Multiple values per key are supported,
+ * it will always return arrays of strings for the value parts.
+ */
+jQuery.getQueryParameters = function(s) {
+ if (typeof s == 'undefined')
+ s = document.location.search;
+ var parts = s.substr(s.indexOf('?') + 1).split('&');
+ var result = {};
+ for (var i = 0; i < parts.length; i++) {
+ var tmp = parts[i].split('=', 2);
+ var key = jQuery.urldecode(tmp[0]);
+ var value = jQuery.urldecode(tmp[1]);
+ if (key in result)
+ result[key].push(value);
+ else
+ result[key] = [value];
+ }
+ return result;
+};
+
+/**
+ * small function to check if an array contains
+ * a given item.
+ */
+jQuery.contains = function(arr, item) {
+ for (var i = 0; i < arr.length; i++) {
+ if (arr[i] == item)
+ return true;
+ }
+ return false;
+};
+
+/**
+ * highlight a given string on a jquery object by wrapping it in
+ * span elements with the given class name.
+ */
+jQuery.fn.highlightText = function(text, className) {
+ function highlight(node) {
+ if (node.nodeType == 3) {
+ var val = node.nodeValue;
+ var pos = val.toLowerCase().indexOf(text);
+ if (pos >= 0 && !jQuery(node.parentNode).hasClass(className)) {
+ var span = document.createElement("span");
+ span.className = className;
+ span.appendChild(document.createTextNode(val.substr(pos, text.length)));
+ node.parentNode.insertBefore(span, node.parentNode.insertBefore(
+ document.createTextNode(val.substr(pos + text.length)),
+ node.nextSibling));
+ node.nodeValue = val.substr(0, pos);
+ }
+ }
+ else if (!jQuery(node).is("button, select, textarea")) {
+ jQuery.each(node.childNodes, function() {
+ highlight(this);
+ });
+ }
+ }
+ return this.each(function() {
+ highlight(this);
+ });
+};
+
+/**
+ * Small JavaScript module for the documentation.
+ */
+var Documentation = {
+
+ init : function() {
+ this.fixFirefoxAnchorBug();
+ this.highlightSearchWords();
+ this.initIndexTable();
+ },
+
+ /**
+ * i18n support
+ */
+ TRANSLATIONS : {},
+ PLURAL_EXPR : function(n) { return n == 1 ? 0 : 1; },
+ LOCALE : 'unknown',
+
+ // gettext and ngettext don't access this so that the functions
+ // can safely bound to a different name (_ = Documentation.gettext)
+ gettext : function(string) {
+ var translated = Documentation.TRANSLATIONS[string];
+ if (typeof translated == 'undefined')
+ return string;
+ return (typeof translated == 'string') ? translated : translated[0];
+ },
+
+ ngettext : function(singular, plural, n) {
+ var translated = Documentation.TRANSLATIONS[singular];
+ if (typeof translated == 'undefined')
+ return (n == 1) ? singular : plural;
+ return translated[Documentation.PLURALEXPR(n)];
+ },
+
+ addTranslations : function(catalog) {
+ for (var key in catalog.messages)
+ this.TRANSLATIONS[key] = catalog.messages[key];
+ this.PLURAL_EXPR = new Function('n', 'return +(' + catalog.plural_expr + ')');
+ this.LOCALE = catalog.locale;
+ },
+
+ /**
+ * add context elements like header anchor links
+ */
+ addContextElements : function() {
+ $('div[id] > :header:first').each(function() {
+ $('<a class="headerlink">\u00B6</a>').
+ attr('href', '#' + this.id).
+ attr('title', _('Permalink to this headline')).
+ appendTo(this);
+ });
+ $('dt[id]').each(function() {
+ $('<a class="headerlink">\u00B6</a>').
+ attr('href', '#' + this.id).
+ attr('title', _('Permalink to this definition')).
+ appendTo(this);
+ });
+ },
+
+ /**
+ * workaround a firefox stupidity
+ */
+ fixFirefoxAnchorBug : function() {
+ if (document.location.hash && $.browser.mozilla)
+ window.setTimeout(function() {
+ document.location.href += '';
+ }, 10);
+ },
+
+ /**
+ * highlight the search words provided in the url in the text
+ */
+ highlightSearchWords : function() {
+ var params = $.getQueryParameters();
+ var terms = (params.highlight) ? params.highlight[0].split(/\s+/) : [];
+ if (terms.length) {
+ var body = $('div.body');
+ window.setTimeout(function() {
+ $.each(terms, function() {
+ body.highlightText(this.toLowerCase(), 'highlighted');
+ });
+ }, 10);
+ $('<p class="highlight-link"><a href="javascript:Documentation.' +
+ 'hideSearchWords()">' + _('Hide Search Matches') + '</a></p>')
+ .appendTo($('#searchbox'));
+ }
+ },
+
+ /**
+ * init the domain index toggle buttons
+ */
+ initIndexTable : function() {
+ var togglers = $('img.toggler').click(function() {
+ var src = $(this).attr('src');
+ var idnum = $(this).attr('id').substr(7);
+ $('tr.cg-' + idnum).toggle();
+ if (src.substr(-9) == 'minus.png')
+ $(this).attr('src', src.substr(0, src.length-9) + 'plus.png');
+ else
+ $(this).attr('src', src.substr(0, src.length-8) + 'minus.png');
+ }).css('display', '');
+ if (DOCUMENTATION_OPTIONS.COLLAPSE_INDEX) {
+ togglers.click();
+ }
+ },
+
+ /**
+ * helper function to hide the search marks again
+ */
+ hideSearchWords : function() {
+ $('#searchbox .highlight-link').fadeOut(300);
+ $('span.highlighted').removeClass('highlighted');
+ },
+
+ /**
+ * make the url absolute
+ */
+ makeURL : function(relativeURL) {
+ return DOCUMENTATION_OPTIONS.URL_ROOT + '/' + relativeURL;
+ },
+
+ /**
+ * get the current relative url
+ */
+ getCurrentURL : function() {
+ var path = document.location.pathname;
+ var parts = path.split(/\//);
+ $.each(DOCUMENTATION_OPTIONS.URL_ROOT.split(/\//), function() {
+ if (this == '..')
+ parts.pop();
+ });
+ var url = parts.join('/');
+ return path.substring(url.lastIndexOf('/') + 1, path.length - 1);
+ }
+};
+
+// quick alias for translations
+_ = Documentation.gettext;
+
+$(document).ready(function() {
+ Documentation.init();
+});
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/down-pressed.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/down-pressed.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/down-pressed.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/down.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/down.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/down.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/file.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/file.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/file.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/haiku.css
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/haiku.css?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_static/haiku.css (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_static/haiku.css Thu May 10 06:54:16 2018
@@ -0,0 +1,371 @@
+/*
+ * haiku.css_t
+ * ~~~~~~~~~~~
+ *
+ * Sphinx stylesheet -- haiku theme.
+ *
+ * Adapted from http://haiku-os.org/docs/Haiku-doc.css.
+ * Original copyright message:
+ *
+ * Copyright 2008-2009, Haiku. All rights reserved.
+ * Distributed under the terms of the MIT License.
+ *
+ * Authors:
+ * Francois Revol <revol at free.fr>
+ * Stephan Assmus <superstippi at gmx.de>
+ * Braden Ewing <brewin at gmail.com>
+ * Humdinger <humdingerb at gmail.com>
+ *
+ * :copyright: Copyright 2007-2011 by the Sphinx team, see AUTHORS.
+ * :license: BSD, see LICENSE for details.
+ *
+ */
+
+ at import url("basic.css");
+
+html {
+ margin: 0px;
+ padding: 0px;
+ background: #FFF url(bg-page.png) top left repeat-x;
+}
+
+body {
+ line-height: 1.5;
+ margin: auto;
+ padding: 0px;
+ font-family: "DejaVu Sans", Arial, Helvetica, sans-serif;
+ min-width: 59em;
+ max-width: 70em;
+ color: #333333;
+}
+
+div.footer {
+ padding: 8px;
+ font-size: 11px;
+ text-align: center;
+ letter-spacing: 0.5px;
+}
+
+/* link colors and text decoration */
+
+a:link {
+ font-weight: bold;
+ text-decoration: none;
+ color: #dc3c01;
+}
+
+a:visited {
+ font-weight: bold;
+ text-decoration: none;
+ color: #892601;
+}
+
+a:hover, a:active {
+ text-decoration: underline;
+ color: #ff4500;
+}
+
+/* Some headers act as anchors, don't give them a hover effect */
+
+h1 a:hover, a:active {
+ text-decoration: none;
+ color: #0c3762;
+}
+
+h2 a:hover, a:active {
+ text-decoration: none;
+ color: #0c3762;
+}
+
+h3 a:hover, a:active {
+ text-decoration: none;
+ color: #0c3762;
+}
+
+h4 a:hover, a:active {
+ text-decoration: none;
+ color: #0c3762;
+}
+
+a.headerlink {
+ color: #a7ce38;
+ padding-left: 5px;
+}
+
+a.headerlink:hover {
+ color: #a7ce38;
+}
+
+/* basic text elements */
+
+div.content {
+ margin-top: 20px;
+ margin-left: 40px;
+ margin-right: 40px;
+ margin-bottom: 50px;
+ font-size: 0.9em;
+}
+
+/* heading and navigation */
+
+div.header {
+ position: relative;
+ left: 0px;
+ top: 0px;
+ height: 85px;
+ /* background: #eeeeee; */
+ padding: 0 40px;
+}
+div.header h1 {
+ font-size: 1.6em;
+ font-weight: normal;
+ letter-spacing: 1px;
+ color: #0c3762;
+ border: 0;
+ margin: 0;
+ padding-top: 15px;
+}
+div.header h1 a {
+ font-weight: normal;
+ color: #0c3762;
+}
+div.header h2 {
+ font-size: 1.3em;
+ font-weight: normal;
+ letter-spacing: 1px;
+ text-transform: uppercase;
+ color: #aaa;
+ border: 0;
+ margin-top: -3px;
+ padding: 0;
+}
+
+div.header img.rightlogo {
+ float: right;
+}
+
+
+div.title {
+ font-size: 1.3em;
+ font-weight: bold;
+ color: #0c3762;
+ border-bottom: dotted thin #e0e0e0;
+ margin-bottom: 25px;
+}
+div.topnav {
+ /* background: #e0e0e0; */
+}
+div.topnav p {
+ margin-top: 0;
+ margin-left: 40px;
+ margin-right: 40px;
+ margin-bottom: 0px;
+ text-align: right;
+ font-size: 0.8em;
+}
+div.bottomnav {
+ background: #eeeeee;
+}
+div.bottomnav p {
+ margin-right: 40px;
+ text-align: right;
+ font-size: 0.8em;
+}
+
+a.uplink {
+ font-weight: normal;
+}
+
+
+/* contents box */
+
+table.index {
+ margin: 0px 0px 30px 30px;
+ padding: 1px;
+ border-width: 1px;
+ border-style: dotted;
+ border-color: #e0e0e0;
+}
+table.index tr.heading {
+ background-color: #e0e0e0;
+ text-align: center;
+ font-weight: bold;
+ font-size: 1.1em;
+}
+table.index tr.index {
+ background-color: #eeeeee;
+}
+table.index td {
+ padding: 5px 20px;
+}
+
+table.index a:link, table.index a:visited {
+ font-weight: normal;
+ text-decoration: none;
+ color: #dc3c01;
+}
+table.index a:hover, table.index a:active {
+ text-decoration: underline;
+ color: #ff4500;
+}
+
+
+/* Haiku User Guide styles and layout */
+
+/* Rounded corner boxes */
+/* Common declarations */
+div.admonition {
+ -webkit-border-radius: 10px;
+ -khtml-border-radius: 10px;
+ -moz-border-radius: 10px;
+ border-radius: 10px;
+ border-style: dotted;
+ border-width: thin;
+ border-color: #dcdcdc;
+ padding: 10px 15px 10px 15px;
+ margin-bottom: 15px;
+ margin-top: 15px;
+}
+div.note {
+ padding: 10px 15px 10px 80px;
+ background: #e4ffde url(alert_info_32.png) 15px 15px no-repeat;
+ min-height: 42px;
+}
+div.warning {
+ padding: 10px 15px 10px 80px;
+ background: #fffbc6 url(alert_warning_32.png) 15px 15px no-repeat;
+ min-height: 42px;
+}
+div.seealso {
+ background: #e4ffde;
+}
+
+/* More layout and styles */
+h1 {
+ font-size: 1.3em;
+ font-weight: bold;
+ color: #0c3762;
+ border-bottom: dotted thin #e0e0e0;
+ margin-top: 30px;
+}
+
+h2 {
+ font-size: 1.2em;
+ font-weight: normal;
+ color: #0c3762;
+ border-bottom: dotted thin #e0e0e0;
+ margin-top: 30px;
+}
+
+h3 {
+ font-size: 1.1em;
+ font-weight: normal;
+ color: #0c3762;
+ margin-top: 30px;
+}
+
+h4 {
+ font-size: 1.0em;
+ font-weight: normal;
+ color: #0c3762;
+ margin-top: 30px;
+}
+
+p {
+ text-align: justify;
+}
+
+p.last {
+ margin-bottom: 0;
+}
+
+ol {
+ padding-left: 20px;
+}
+
+ul {
+ padding-left: 5px;
+ margin-top: 3px;
+}
+
+li {
+ line-height: 1.3;
+}
+
+div.content ul > li {
+ -moz-background-clip:border;
+ -moz-background-inline-policy:continuous;
+ -moz-background-origin:padding;
+ background: transparent url(bullet_orange.png) no-repeat scroll left 0.45em;
+ list-style-image: none;
+ list-style-type: none;
+ padding: 0 0 0 1.666em;
+ margin-bottom: 3px;
+}
+
+td {
+ vertical-align: top;
+}
+
+tt {
+ background-color: #e2e2e2;
+ font-size: 1.0em;
+ font-family: monospace;
+}
+
+pre {
+ border-color: #0c3762;
+ border-style: dotted;
+ border-width: thin;
+ margin: 0 0 12px 0;
+ padding: 0.8em;
+ background-color: #f0f0f0;
+}
+
+hr {
+ border-top: 1px solid #ccc;
+ border-bottom: 0;
+ border-right: 0;
+ border-left: 0;
+ margin-bottom: 10px;
+ margin-top: 20px;
+}
+
+/* printer only pretty stuff */
+ at media print {
+ .noprint {
+ display: none;
+ }
+ /* for acronyms we want their definitions inlined at print time */
+ acronym[title]:after {
+ font-size: small;
+ content: " (" attr(title) ")";
+ font-style: italic;
+ }
+ /* and not have mozilla dotted underline */
+ acronym {
+ border: none;
+ }
+ div.topnav, div.bottomnav, div.header, table.index {
+ display: none;
+ }
+ div.content {
+ margin: 0px;
+ padding: 0px;
+ }
+ html {
+ background: #FFF;
+ }
+}
+
+.viewcode-back {
+ font-family: "DejaVu Sans", Arial, Helvetica, sans-serif;
+}
+
+div.viewcode-block:target {
+ background-color: #f4debf;
+ border-top: 1px solid #ac9;
+ border-bottom: 1px solid #ac9;
+ margin: -1px -12px;
+ padding: 0 12px;
+}
\ No newline at end of file
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/jquery.js
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/jquery.js?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_static/jquery.js (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_static/jquery.js Thu May 10 06:54:16 2018
@@ -0,0 +1,154 @@
+/*!
+ * jQuery JavaScript Library v1.4.2
+ * http://jquery.com/
+ *
+ * Copyright 2010, John Resig
+ * Dual licensed under the MIT or GPL Version 2 licenses.
+ * http://jquery.org/license
+ *
+ * Includes Sizzle.js
+ * http://sizzlejs.com/
+ * Copyright 2010, The Dojo Foundation
+ * Released under the MIT, BSD, and GPL Licenses.
+ *
+ * Date: Sat Feb 13 22:33:48 2010 -0500
+ */
+(function(A,w){function ma(){if(!c.isReady){try{s.documentElement.doScroll("left")}catch(a){setTimeout(ma,1);return}c.ready()}}function Qa(a,b){b.src?c.ajax({url:b.src,async:false,dataType:"script"}):c.globalEval(b.text||b.textContent||b.innerHTML||"");b.parentNode&&b.parentNode.removeChild(b)}function X(a,b,d,f,e,j){var i=a.length;if(typeof b==="object"){for(var o in b)X(a,o,b[o],f,e,d);return a}if(d!==w){f=!j&&f&&c.isFunction(d);for(o=0;o<i;o++)e(a[o],b,f?d.call(a[o],o,e(a[o],b)):d,j);return a}return i?
+e(a[0],b):w}function J(){return(new Date).getTime()}function Y(){return false}function Z(){return true}function na(a,b,d){d[0].type=a;return c.event.handle.apply(b,d)}function oa(a){var b,d=[],f=[],e=arguments,j,i,o,k,n,r;i=c.data(this,"events");if(!(a.liveFired===this||!i||!i.live||a.button&&a.type==="click")){a.liveFired=this;var u=i.live.slice(0);for(k=0;k<u.length;k++){i=u[k];i.origType.replace(O,"")===a.type?f.push(i.selector):u.splice(k--,1)}j=c(a.target).closest(f,a.currentTarget);n=0;for(r=
+j.length;n<r;n++)for(k=0;k<u.length;k++){i=u[k];if(j[n].selector===i.selector){o=j[n].elem;f=null;if(i.preType==="mouseenter"||i.preType==="mouseleave")f=c(a.relatedTarget).closest(i.selector)[0];if(!f||f!==o)d.push({elem:o,handleObj:i})}}n=0;for(r=d.length;n<r;n++){j=d[n];a.currentTarget=j.elem;a.data=j.handleObj.data;a.handleObj=j.handleObj;if(j.handleObj.origHandler.apply(j.elem,e)===false){b=false;break}}return b}}function pa(a,b){return"live."+(a&&a!=="*"?a+".":"")+b.replace(/\./g,"`").replace(/ /g,
+"&")}function qa(a){return!a||!a.parentNode||a.parentNode.nodeType===11}function ra(a,b){var d=0;b.each(function(){if(this.nodeName===(a[d]&&a[d].nodeName)){var f=c.data(a[d++]),e=c.data(this,f);if(f=f&&f.events){delete e.handle;e.events={};for(var j in f)for(var i in f[j])c.event.add(this,j,f[j][i],f[j][i].data)}}})}function sa(a,b,d){var f,e,j;b=b&&b[0]?b[0].ownerDocument||b[0]:s;if(a.length===1&&typeof a[0]==="string"&&a[0].length<512&&b===s&&!ta.test(a[0])&&(c.support.checkClone||!ua.test(a[0]))){e=
+true;if(j=c.fragments[a[0]])if(j!==1)f=j}if(!f){f=b.createDocumentFragment();c.clean(a,b,f,d)}if(e)c.fragments[a[0]]=j?f:1;return{fragment:f,cacheable:e}}function K(a,b){var d={};c.each(va.concat.apply([],va.slice(0,b)),function(){d[this]=a});return d}function wa(a){return"scrollTo"in a&&a.document?a:a.nodeType===9?a.defaultView||a.parentWindow:false}var c=function(a,b){return new c.fn.init(a,b)},Ra=A.jQuery,Sa=A.$,s=A.document,T,Ta=/^[^<]*(<[\w\W]+>)[^>]*$|^#([\w-]+)$/,Ua=/^.[^:#\[\.,]*$/,Va=/\S/,
+Wa=/^(\s|\u00A0)+|(\s|\u00A0)+$/g,Xa=/^<(\w+)\s*\/?>(?:<\/\1>)?$/,P=navigator.userAgent,xa=false,Q=[],L,$=Object.prototype.toString,aa=Object.prototype.hasOwnProperty,ba=Array.prototype.push,R=Array.prototype.slice,ya=Array.prototype.indexOf;c.fn=c.prototype={init:function(a,b){var d,f;if(!a)return this;if(a.nodeType){this.context=this[0]=a;this.length=1;return this}if(a==="body"&&!b){this.context=s;this[0]=s.body;this.selector="body";this.length=1;return this}if(typeof a==="string")if((d=Ta.exec(a))&&
+(d[1]||!b))if(d[1]){f=b?b.ownerDocument||b:s;if(a=Xa.exec(a))if(c.isPlainObject(b)){a=[s.createElement(a[1])];c.fn.attr.call(a,b,true)}else a=[f.createElement(a[1])];else{a=sa([d[1]],[f]);a=(a.cacheable?a.fragment.cloneNode(true):a.fragment).childNodes}return c.merge(this,a)}else{if(b=s.getElementById(d[2])){if(b.id!==d[2])return T.find(a);this.length=1;this[0]=b}this.context=s;this.selector=a;return this}else if(!b&&/^\w+$/.test(a)){this.selector=a;this.context=s;a=s.getElementsByTagName(a);return c.merge(this,
+a)}else return!b||b.jquery?(b||T).find(a):c(b).find(a);else if(c.isFunction(a))return T.ready(a);if(a.selector!==w){this.selector=a.selector;this.context=a.context}return c.makeArray(a,this)},selector:"",jquery:"1.4.2",length:0,size:function(){return this.length},toArray:function(){return R.call(this,0)},get:function(a){return a==null?this.toArray():a<0?this.slice(a)[0]:this[a]},pushStack:function(a,b,d){var f=c();c.isArray(a)?ba.apply(f,a):c.merge(f,a);f.prevObject=this;f.context=this.context;if(b===
+"find")f.selector=this.selector+(this.selector?" ":"")+d;else if(b)f.selector=this.selector+"."+b+"("+d+")";return f},each:function(a,b){return c.each(this,a,b)},ready:function(a){c.bindReady();if(c.isReady)a.call(s,c);else Q&&Q.push(a);return this},eq:function(a){return a===-1?this.slice(a):this.slice(a,+a+1)},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},slice:function(){return this.pushStack(R.apply(this,arguments),"slice",R.call(arguments).join(","))},map:function(a){return this.pushStack(c.map(this,
+function(b,d){return a.call(b,d,b)}))},end:function(){return this.prevObject||c(null)},push:ba,sort:[].sort,splice:[].splice};c.fn.init.prototype=c.fn;c.extend=c.fn.extend=function(){var a=arguments[0]||{},b=1,d=arguments.length,f=false,e,j,i,o;if(typeof a==="boolean"){f=a;a=arguments[1]||{};b=2}if(typeof a!=="object"&&!c.isFunction(a))a={};if(d===b){a=this;--b}for(;b<d;b++)if((e=arguments[b])!=null)for(j in e){i=a[j];o=e[j];if(a!==o)if(f&&o&&(c.isPlainObject(o)||c.isArray(o))){i=i&&(c.isPlainObject(i)||
+c.isArray(i))?i:c.isArray(o)?[]:{};a[j]=c.extend(f,i,o)}else if(o!==w)a[j]=o}return a};c.extend({noConflict:function(a){A.$=Sa;if(a)A.jQuery=Ra;return c},isReady:false,ready:function(){if(!c.isReady){if(!s.body)return setTimeout(c.ready,13);c.isReady=true;if(Q){for(var a,b=0;a=Q[b++];)a.call(s,c);Q=null}c.fn.triggerHandler&&c(s).triggerHandler("ready")}},bindReady:function(){if(!xa){xa=true;if(s.readyState==="complete")return c.ready();if(s.addEventListener){s.addEventListener("DOMContentLoaded",
+L,false);A.addEventListener("load",c.ready,false)}else if(s.attachEvent){s.attachEvent("onreadystatechange",L);A.attachEvent("onload",c.ready);var a=false;try{a=A.frameElement==null}catch(b){}s.documentElement.doScroll&&a&&ma()}}},isFunction:function(a){return $.call(a)==="[object Function]"},isArray:function(a){return $.call(a)==="[object Array]"},isPlainObject:function(a){if(!a||$.call(a)!=="[object Object]"||a.nodeType||a.setInterval)return false;if(a.constructor&&!aa.call(a,"constructor")&&!aa.call(a.constructor.prototype,
+"isPrototypeOf"))return false;var b;for(b in a);return b===w||aa.call(a,b)},isEmptyObject:function(a){for(var b in a)return false;return true},error:function(a){throw a;},parseJSON:function(a){if(typeof a!=="string"||!a)return null;a=c.trim(a);if(/^[\],:{}\s]*$/.test(a.replace(/\\(?:["\\\/bfnrt]|u[0-9a-fA-F]{4})/g,"@").replace(/"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g,"]").replace(/(?:^|:|,)(?:\s*\[)+/g,"")))return A.JSON&&A.JSON.parse?A.JSON.parse(a):(new Function("return "+
+a))();else c.error("Invalid JSON: "+a)},noop:function(){},globalEval:function(a){if(a&&Va.test(a)){var b=s.getElementsByTagName("head")[0]||s.documentElement,d=s.createElement("script");d.type="text/javascript";if(c.support.scriptEval)d.appendChild(s.createTextNode(a));else d.text=a;b.insertBefore(d,b.firstChild);b.removeChild(d)}},nodeName:function(a,b){return a.nodeName&&a.nodeName.toUpperCase()===b.toUpperCase()},each:function(a,b,d){var f,e=0,j=a.length,i=j===w||c.isFunction(a);if(d)if(i)for(f in a){if(b.apply(a[f],
+d)===false)break}else for(;e<j;){if(b.apply(a[e++],d)===false)break}else if(i)for(f in a){if(b.call(a[f],f,a[f])===false)break}else for(d=a[0];e<j&&b.call(d,e,d)!==false;d=a[++e]);return a},trim:function(a){return(a||"").replace(Wa,"")},makeArray:function(a,b){b=b||[];if(a!=null)a.length==null||typeof a==="string"||c.isFunction(a)||typeof a!=="function"&&a.setInterval?ba.call(b,a):c.merge(b,a);return b},inArray:function(a,b){if(b.indexOf)return b.indexOf(a);for(var d=0,f=b.length;d<f;d++)if(b[d]===
+a)return d;return-1},merge:function(a,b){var d=a.length,f=0;if(typeof b.length==="number")for(var e=b.length;f<e;f++)a[d++]=b[f];else for(;b[f]!==w;)a[d++]=b[f++];a.length=d;return a},grep:function(a,b,d){for(var f=[],e=0,j=a.length;e<j;e++)!d!==!b(a[e],e)&&f.push(a[e]);return f},map:function(a,b,d){for(var f=[],e,j=0,i=a.length;j<i;j++){e=b(a[j],j,d);if(e!=null)f[f.length]=e}return f.concat.apply([],f)},guid:1,proxy:function(a,b,d){if(arguments.length===2)if(typeof b==="string"){d=a;a=d[b];b=w}else if(b&&
+!c.isFunction(b)){d=b;b=w}if(!b&&a)b=function(){return a.apply(d||this,arguments)};if(a)b.guid=a.guid=a.guid||b.guid||c.guid++;return b},uaMatch:function(a){a=a.toLowerCase();a=/(webkit)[ \/]([\w.]+)/.exec(a)||/(opera)(?:.*version)?[ \/]([\w.]+)/.exec(a)||/(msie) ([\w.]+)/.exec(a)||!/compatible/.test(a)&&/(mozilla)(?:.*? rv:([\w.]+))?/.exec(a)||[];return{browser:a[1]||"",version:a[2]||"0"}},browser:{}});P=c.uaMatch(P);if(P.browser){c.browser[P.browser]=true;c.browser.version=P.version}if(c.browser.webkit)c.browser.safari=
+true;if(ya)c.inArray=function(a,b){return ya.call(b,a)};T=c(s);if(s.addEventListener)L=function(){s.removeEventListener("DOMContentLoaded",L,false);c.ready()};else if(s.attachEvent)L=function(){if(s.readyState==="complete"){s.detachEvent("onreadystatechange",L);c.ready()}};(function(){c.support={};var a=s.documentElement,b=s.createElement("script"),d=s.createElement("div"),f="script"+J();d.style.display="none";d.innerHTML=" <link/><table></table><a href='/a' style='color:red;float:left;opacity:.55;'>a</a><input type='checkbox'/>";
+var e=d.getElementsByTagName("*"),j=d.getElementsByTagName("a")[0];if(!(!e||!e.length||!j)){c.support={leadingWhitespace:d.firstChild.nodeType===3,tbody:!d.getElementsByTagName("tbody").length,htmlSerialize:!!d.getElementsByTagName("link").length,style:/red/.test(j.getAttribute("style")),hrefNormalized:j.getAttribute("href")==="/a",opacity:/^0.55$/.test(j.style.opacity),cssFloat:!!j.style.cssFloat,checkOn:d.getElementsByTagName("input")[0].value==="on",optSelected:s.createElement("select").appendChild(s.createElement("option")).selected,
+parentNode:d.removeChild(d.appendChild(s.createElement("div"))).parentNode===null,deleteExpando:true,checkClone:false,scriptEval:false,noCloneEvent:true,boxModel:null};b.type="text/javascript";try{b.appendChild(s.createTextNode("window."+f+"=1;"))}catch(i){}a.insertBefore(b,a.firstChild);if(A[f]){c.support.scriptEval=true;delete A[f]}try{delete b.test}catch(o){c.support.deleteExpando=false}a.removeChild(b);if(d.attachEvent&&d.fireEvent){d.attachEvent("onclick",function k(){c.support.noCloneEvent=
+false;d.detachEvent("onclick",k)});d.cloneNode(true).fireEvent("onclick")}d=s.createElement("div");d.innerHTML="<input type='radio' name='radiotest' checked='checked'/>";a=s.createDocumentFragment();a.appendChild(d.firstChild);c.support.checkClone=a.cloneNode(true).cloneNode(true).lastChild.checked;c(function(){var k=s.createElement("div");k.style.width=k.style.paddingLeft="1px";s.body.appendChild(k);c.boxModel=c.support.boxModel=k.offsetWidth===2;s.body.removeChild(k).style.display="none"});a=function(k){var n=
+s.createElement("div");k="on"+k;var r=k in n;if(!r){n.setAttribute(k,"return;");r=typeof n[k]==="function"}return r};c.support.submitBubbles=a("submit");c.support.changeBubbles=a("change");a=b=d=e=j=null}})();c.props={"for":"htmlFor","class":"className",readonly:"readOnly",maxlength:"maxLength",cellspacing:"cellSpacing",rowspan:"rowSpan",colspan:"colSpan",tabindex:"tabIndex",usemap:"useMap",frameborder:"frameBorder"};var G="jQuery"+J(),Ya=0,za={};c.extend({cache:{},expando:G,noData:{embed:true,object:true,
+applet:true},data:function(a,b,d){if(!(a.nodeName&&c.noData[a.nodeName.toLowerCase()])){a=a==A?za:a;var f=a[G],e=c.cache;if(!f&&typeof b==="string"&&d===w)return null;f||(f=++Ya);if(typeof b==="object"){a[G]=f;e[f]=c.extend(true,{},b)}else if(!e[f]){a[G]=f;e[f]={}}a=e[f];if(d!==w)a[b]=d;return typeof b==="string"?a[b]:a}},removeData:function(a,b){if(!(a.nodeName&&c.noData[a.nodeName.toLowerCase()])){a=a==A?za:a;var d=a[G],f=c.cache,e=f[d];if(b){if(e){delete e[b];c.isEmptyObject(e)&&c.removeData(a)}}else{if(c.support.deleteExpando)delete a[c.expando];
+else a.removeAttribute&&a.removeAttribute(c.expando);delete f[d]}}}});c.fn.extend({data:function(a,b){if(typeof a==="undefined"&&this.length)return c.data(this[0]);else if(typeof a==="object")return this.each(function(){c.data(this,a)});var d=a.split(".");d[1]=d[1]?"."+d[1]:"";if(b===w){var f=this.triggerHandler("getData"+d[1]+"!",[d[0]]);if(f===w&&this.length)f=c.data(this[0],a);return f===w&&d[1]?this.data(d[0]):f}else return this.trigger("setData"+d[1]+"!",[d[0],b]).each(function(){c.data(this,
+a,b)})},removeData:function(a){return this.each(function(){c.removeData(this,a)})}});c.extend({queue:function(a,b,d){if(a){b=(b||"fx")+"queue";var f=c.data(a,b);if(!d)return f||[];if(!f||c.isArray(d))f=c.data(a,b,c.makeArray(d));else f.push(d);return f}},dequeue:function(a,b){b=b||"fx";var d=c.queue(a,b),f=d.shift();if(f==="inprogress")f=d.shift();if(f){b==="fx"&&d.unshift("inprogress");f.call(a,function(){c.dequeue(a,b)})}}});c.fn.extend({queue:function(a,b){if(typeof a!=="string"){b=a;a="fx"}if(b===
+w)return c.queue(this[0],a);return this.each(function(){var d=c.queue(this,a,b);a==="fx"&&d[0]!=="inprogress"&&c.dequeue(this,a)})},dequeue:function(a){return this.each(function(){c.dequeue(this,a)})},delay:function(a,b){a=c.fx?c.fx.speeds[a]||a:a;b=b||"fx";return this.queue(b,function(){var d=this;setTimeout(function(){c.dequeue(d,b)},a)})},clearQueue:function(a){return this.queue(a||"fx",[])}});var Aa=/[\n\t]/g,ca=/\s+/,Za=/\r/g,$a=/href|src|style/,ab=/(button|input)/i,bb=/(button|input|object|select|textarea)/i,
+cb=/^(a|area)$/i,Ba=/radio|checkbox/;c.fn.extend({attr:function(a,b){return X(this,a,b,true,c.attr)},removeAttr:function(a){return this.each(function(){c.attr(this,a,"");this.nodeType===1&&this.removeAttribute(a)})},addClass:function(a){if(c.isFunction(a))return this.each(function(n){var r=c(this);r.addClass(a.call(this,n,r.attr("class")))});if(a&&typeof a==="string")for(var b=(a||"").split(ca),d=0,f=this.length;d<f;d++){var e=this[d];if(e.nodeType===1)if(e.className){for(var j=" "+e.className+" ",
+i=e.className,o=0,k=b.length;o<k;o++)if(j.indexOf(" "+b[o]+" ")<0)i+=" "+b[o];e.className=c.trim(i)}else e.className=a}return this},removeClass:function(a){if(c.isFunction(a))return this.each(function(k){var n=c(this);n.removeClass(a.call(this,k,n.attr("class")))});if(a&&typeof a==="string"||a===w)for(var b=(a||"").split(ca),d=0,f=this.length;d<f;d++){var e=this[d];if(e.nodeType===1&&e.className)if(a){for(var j=(" "+e.className+" ").replace(Aa," "),i=0,o=b.length;i<o;i++)j=j.replace(" "+b[i]+" ",
+" ");e.className=c.trim(j)}else e.className=""}return this},toggleClass:function(a,b){var d=typeof a,f=typeof b==="boolean";if(c.isFunction(a))return this.each(function(e){var j=c(this);j.toggleClass(a.call(this,e,j.attr("class"),b),b)});return this.each(function(){if(d==="string")for(var e,j=0,i=c(this),o=b,k=a.split(ca);e=k[j++];){o=f?o:!i.hasClass(e);i[o?"addClass":"removeClass"](e)}else if(d==="undefined"||d==="boolean"){this.className&&c.data(this,"__className__",this.className);this.className=
+this.className||a===false?"":c.data(this,"__className__")||""}})},hasClass:function(a){a=" "+a+" ";for(var b=0,d=this.length;b<d;b++)if((" "+this[b].className+" ").replace(Aa," ").indexOf(a)>-1)return true;return false},val:function(a){if(a===w){var b=this[0];if(b){if(c.nodeName(b,"option"))return(b.attributes.value||{}).specified?b.value:b.text;if(c.nodeName(b,"select")){var d=b.selectedIndex,f=[],e=b.options;b=b.type==="select-one";if(d<0)return null;var j=b?d:0;for(d=b?d+1:e.length;j<d;j++){var i=
+e[j];if(i.selected){a=c(i).val();if(b)return a;f.push(a)}}return f}if(Ba.test(b.type)&&!c.support.checkOn)return b.getAttribute("value")===null?"on":b.value;return(b.value||"").replace(Za,"")}return w}var o=c.isFunction(a);return this.each(function(k){var n=c(this),r=a;if(this.nodeType===1){if(o)r=a.call(this,k,n.val());if(typeof r==="number")r+="";if(c.isArray(r)&&Ba.test(this.type))this.checked=c.inArray(n.val(),r)>=0;else if(c.nodeName(this,"select")){var u=c.makeArray(r);c("option",this).each(function(){this.selected=
+c.inArray(c(this).val(),u)>=0});if(!u.length)this.selectedIndex=-1}else this.value=r}})}});c.extend({attrFn:{val:true,css:true,html:true,text:true,data:true,width:true,height:true,offset:true},attr:function(a,b,d,f){if(!a||a.nodeType===3||a.nodeType===8)return w;if(f&&b in c.attrFn)return c(a)[b](d);f=a.nodeType!==1||!c.isXMLDoc(a);var e=d!==w;b=f&&c.props[b]||b;if(a.nodeType===1){var j=$a.test(b);if(b in a&&f&&!j){if(e){b==="type"&&ab.test(a.nodeName)&&a.parentNode&&c.error("type property can't be changed");
+a[b]=d}if(c.nodeName(a,"form")&&a.getAttributeNode(b))return a.getAttributeNode(b).nodeValue;if(b==="tabIndex")return(b=a.getAttributeNode("tabIndex"))&&b.specified?b.value:bb.test(a.nodeName)||cb.test(a.nodeName)&&a.href?0:w;return a[b]}if(!c.support.style&&f&&b==="style"){if(e)a.style.cssText=""+d;return a.style.cssText}e&&a.setAttribute(b,""+d);a=!c.support.hrefNormalized&&f&&j?a.getAttribute(b,2):a.getAttribute(b);return a===null?w:a}return c.style(a,b,d)}});var O=/\.(.*)$/,db=function(a){return a.replace(/[^\w\s\.\|`]/g,
+function(b){return"\\"+b})};c.event={add:function(a,b,d,f){if(!(a.nodeType===3||a.nodeType===8)){if(a.setInterval&&a!==A&&!a.frameElement)a=A;var e,j;if(d.handler){e=d;d=e.handler}if(!d.guid)d.guid=c.guid++;if(j=c.data(a)){var i=j.events=j.events||{},o=j.handle;if(!o)j.handle=o=function(){return typeof c!=="undefined"&&!c.event.triggered?c.event.handle.apply(o.elem,arguments):w};o.elem=a;b=b.split(" ");for(var k,n=0,r;k=b[n++];){j=e?c.extend({},e):{handler:d,data:f};if(k.indexOf(".")>-1){r=k.split(".");
+k=r.shift();j.namespace=r.slice(0).sort().join(".")}else{r=[];j.namespace=""}j.type=k;j.guid=d.guid;var u=i[k],z=c.event.special[k]||{};if(!u){u=i[k]=[];if(!z.setup||z.setup.call(a,f,r,o)===false)if(a.addEventListener)a.addEventListener(k,o,false);else a.attachEvent&&a.attachEvent("on"+k,o)}if(z.add){z.add.call(a,j);if(!j.handler.guid)j.handler.guid=d.guid}u.push(j);c.event.global[k]=true}a=null}}},global:{},remove:function(a,b,d,f){if(!(a.nodeType===3||a.nodeType===8)){var e,j=0,i,o,k,n,r,u,z=c.data(a),
+C=z&&z.events;if(z&&C){if(b&&b.type){d=b.handler;b=b.type}if(!b||typeof b==="string"&&b.charAt(0)==="."){b=b||"";for(e in C)c.event.remove(a,e+b)}else{for(b=b.split(" ");e=b[j++];){n=e;i=e.indexOf(".")<0;o=[];if(!i){o=e.split(".");e=o.shift();k=new RegExp("(^|\\.)"+c.map(o.slice(0).sort(),db).join("\\.(?:.*\\.)?")+"(\\.|$)")}if(r=C[e])if(d){n=c.event.special[e]||{};for(B=f||0;B<r.length;B++){u=r[B];if(d.guid===u.guid){if(i||k.test(u.namespace)){f==null&&r.splice(B--,1);n.remove&&n.remove.call(a,u)}if(f!=
+null)break}}if(r.length===0||f!=null&&r.length===1){if(!n.teardown||n.teardown.call(a,o)===false)Ca(a,e,z.handle);delete C[e]}}else for(var B=0;B<r.length;B++){u=r[B];if(i||k.test(u.namespace)){c.event.remove(a,n,u.handler,B);r.splice(B--,1)}}}if(c.isEmptyObject(C)){if(b=z.handle)b.elem=null;delete z.events;delete z.handle;c.isEmptyObject(z)&&c.removeData(a)}}}}},trigger:function(a,b,d,f){var e=a.type||a;if(!f){a=typeof a==="object"?a[G]?a:c.extend(c.Event(e),a):c.Event(e);if(e.indexOf("!")>=0){a.type=
+e=e.slice(0,-1);a.exclusive=true}if(!d){a.stopPropagation();c.event.global[e]&&c.each(c.cache,function(){this.events&&this.events[e]&&c.event.trigger(a,b,this.handle.elem)})}if(!d||d.nodeType===3||d.nodeType===8)return w;a.result=w;a.target=d;b=c.makeArray(b);b.unshift(a)}a.currentTarget=d;(f=c.data(d,"handle"))&&f.apply(d,b);f=d.parentNode||d.ownerDocument;try{if(!(d&&d.nodeName&&c.noData[d.nodeName.toLowerCase()]))if(d["on"+e]&&d["on"+e].apply(d,b)===false)a.result=false}catch(j){}if(!a.isPropagationStopped()&&
+f)c.event.trigger(a,b,f,true);else if(!a.isDefaultPrevented()){f=a.target;var i,o=c.nodeName(f,"a")&&e==="click",k=c.event.special[e]||{};if((!k._default||k._default.call(d,a)===false)&&!o&&!(f&&f.nodeName&&c.noData[f.nodeName.toLowerCase()])){try{if(f[e]){if(i=f["on"+e])f["on"+e]=null;c.event.triggered=true;f[e]()}}catch(n){}if(i)f["on"+e]=i;c.event.triggered=false}}},handle:function(a){var b,d,f,e;a=arguments[0]=c.event.fix(a||A.event);a.currentTarget=this;b=a.type.indexOf(".")<0&&!a.exclusive;
+if(!b){d=a.type.split(".");a.type=d.shift();f=new RegExp("(^|\\.)"+d.slice(0).sort().join("\\.(?:.*\\.)?")+"(\\.|$)")}e=c.data(this,"events");d=e[a.type];if(e&&d){d=d.slice(0);e=0;for(var j=d.length;e<j;e++){var i=d[e];if(b||f.test(i.namespace)){a.handler=i.handler;a.data=i.data;a.handleObj=i;i=i.handler.apply(this,arguments);if(i!==w){a.result=i;if(i===false){a.preventDefault();a.stopPropagation()}}if(a.isImmediatePropagationStopped())break}}}return a.result},props:"altKey attrChange attrName bubbles button cancelable charCode clientX clientY ctrlKey currentTarget data detail eventPhase fromElement handler keyCode layerX layerY metaKey newValue offsetX offsetY originalTarget pageX pageY prevValue relatedNode relatedTarget screenX screenY shiftKey srcElement target toElement view wheelDelta which".split(" "),
+fix:function(a){if(a[G])return a;var b=a;a=c.Event(b);for(var d=this.props.length,f;d;){f=this.props[--d];a[f]=b[f]}if(!a.target)a.target=a.srcElement||s;if(a.target.nodeType===3)a.target=a.target.parentNode;if(!a.relatedTarget&&a.fromElement)a.relatedTarget=a.fromElement===a.target?a.toElement:a.fromElement;if(a.pageX==null&&a.clientX!=null){b=s.documentElement;d=s.body;a.pageX=a.clientX+(b&&b.scrollLeft||d&&d.scrollLeft||0)-(b&&b.clientLeft||d&&d.clientLeft||0);a.pageY=a.clientY+(b&&b.scrollTop||
+d&&d.scrollTop||0)-(b&&b.clientTop||d&&d.clientTop||0)}if(!a.which&&(a.charCode||a.charCode===0?a.charCode:a.keyCode))a.which=a.charCode||a.keyCode;if(!a.metaKey&&a.ctrlKey)a.metaKey=a.ctrlKey;if(!a.which&&a.button!==w)a.which=a.button&1?1:a.button&2?3:a.button&4?2:0;return a},guid:1E8,proxy:c.proxy,special:{ready:{setup:c.bindReady,teardown:c.noop},live:{add:function(a){c.event.add(this,a.origType,c.extend({},a,{handler:oa}))},remove:function(a){var b=true,d=a.origType.replace(O,"");c.each(c.data(this,
+"events").live||[],function(){if(d===this.origType.replace(O,""))return b=false});b&&c.event.remove(this,a.origType,oa)}},beforeunload:{setup:function(a,b,d){if(this.setInterval)this.onbeforeunload=d;return false},teardown:function(a,b){if(this.onbeforeunload===b)this.onbeforeunload=null}}}};var Ca=s.removeEventListener?function(a,b,d){a.removeEventListener(b,d,false)}:function(a,b,d){a.detachEvent("on"+b,d)};c.Event=function(a){if(!this.preventDefault)return new c.Event(a);if(a&&a.type){this.originalEvent=
+a;this.type=a.type}else this.type=a;this.timeStamp=J();this[G]=true};c.Event.prototype={preventDefault:function(){this.isDefaultPrevented=Z;var a=this.originalEvent;if(a){a.preventDefault&&a.preventDefault();a.returnValue=false}},stopPropagation:function(){this.isPropagationStopped=Z;var a=this.originalEvent;if(a){a.stopPropagation&&a.stopPropagation();a.cancelBubble=true}},stopImmediatePropagation:function(){this.isImmediatePropagationStopped=Z;this.stopPropagation()},isDefaultPrevented:Y,isPropagationStopped:Y,
+isImmediatePropagationStopped:Y};var Da=function(a){var b=a.relatedTarget;try{for(;b&&b!==this;)b=b.parentNode;if(b!==this){a.type=a.data;c.event.handle.apply(this,arguments)}}catch(d){}},Ea=function(a){a.type=a.data;c.event.handle.apply(this,arguments)};c.each({mouseenter:"mouseover",mouseleave:"mouseout"},function(a,b){c.event.special[a]={setup:function(d){c.event.add(this,b,d&&d.selector?Ea:Da,a)},teardown:function(d){c.event.remove(this,b,d&&d.selector?Ea:Da)}}});if(!c.support.submitBubbles)c.event.special.submit=
+{setup:function(){if(this.nodeName.toLowerCase()!=="form"){c.event.add(this,"click.specialSubmit",function(a){var b=a.target,d=b.type;if((d==="submit"||d==="image")&&c(b).closest("form").length)return na("submit",this,arguments)});c.event.add(this,"keypress.specialSubmit",function(a){var b=a.target,d=b.type;if((d==="text"||d==="password")&&c(b).closest("form").length&&a.keyCode===13)return na("submit",this,arguments)})}else return false},teardown:function(){c.event.remove(this,".specialSubmit")}};
+if(!c.support.changeBubbles){var da=/textarea|input|select/i,ea,Fa=function(a){var b=a.type,d=a.value;if(b==="radio"||b==="checkbox")d=a.checked;else if(b==="select-multiple")d=a.selectedIndex>-1?c.map(a.options,function(f){return f.selected}).join("-"):"";else if(a.nodeName.toLowerCase()==="select")d=a.selectedIndex;return d},fa=function(a,b){var d=a.target,f,e;if(!(!da.test(d.nodeName)||d.readOnly)){f=c.data(d,"_change_data");e=Fa(d);if(a.type!=="focusout"||d.type!=="radio")c.data(d,"_change_data",
+e);if(!(f===w||e===f))if(f!=null||e){a.type="change";return c.event.trigger(a,b,d)}}};c.event.special.change={filters:{focusout:fa,click:function(a){var b=a.target,d=b.type;if(d==="radio"||d==="checkbox"||b.nodeName.toLowerCase()==="select")return fa.call(this,a)},keydown:function(a){var b=a.target,d=b.type;if(a.keyCode===13&&b.nodeName.toLowerCase()!=="textarea"||a.keyCode===32&&(d==="checkbox"||d==="radio")||d==="select-multiple")return fa.call(this,a)},beforeactivate:function(a){a=a.target;c.data(a,
+"_change_data",Fa(a))}},setup:function(){if(this.type==="file")return false;for(var a in ea)c.event.add(this,a+".specialChange",ea[a]);return da.test(this.nodeName)},teardown:function(){c.event.remove(this,".specialChange");return da.test(this.nodeName)}};ea=c.event.special.change.filters}s.addEventListener&&c.each({focus:"focusin",blur:"focusout"},function(a,b){function d(f){f=c.event.fix(f);f.type=b;return c.event.handle.call(this,f)}c.event.special[b]={setup:function(){this.addEventListener(a,
+d,true)},teardown:function(){this.removeEventListener(a,d,true)}}});c.each(["bind","one"],function(a,b){c.fn[b]=function(d,f,e){if(typeof d==="object"){for(var j in d)this[b](j,f,d[j],e);return this}if(c.isFunction(f)){e=f;f=w}var i=b==="one"?c.proxy(e,function(k){c(this).unbind(k,i);return e.apply(this,arguments)}):e;if(d==="unload"&&b!=="one")this.one(d,f,e);else{j=0;for(var o=this.length;j<o;j++)c.event.add(this[j],d,i,f)}return this}});c.fn.extend({unbind:function(a,b){if(typeof a==="object"&&
+!a.preventDefault)for(var d in a)this.unbind(d,a[d]);else{d=0;for(var f=this.length;d<f;d++)c.event.remove(this[d],a,b)}return this},delegate:function(a,b,d,f){return this.live(b,d,f,a)},undelegate:function(a,b,d){return arguments.length===0?this.unbind("live"):this.die(b,null,d,a)},trigger:function(a,b){return this.each(function(){c.event.trigger(a,b,this)})},triggerHandler:function(a,b){if(this[0]){a=c.Event(a);a.preventDefault();a.stopPropagation();c.event.trigger(a,b,this[0]);return a.result}},
+toggle:function(a){for(var b=arguments,d=1;d<b.length;)c.proxy(a,b[d++]);return this.click(c.proxy(a,function(f){var e=(c.data(this,"lastToggle"+a.guid)||0)%d;c.data(this,"lastToggle"+a.guid,e+1);f.preventDefault();return b[e].apply(this,arguments)||false}))},hover:function(a,b){return this.mouseenter(a).mouseleave(b||a)}});var Ga={focus:"focusin",blur:"focusout",mouseenter:"mouseover",mouseleave:"mouseout"};c.each(["live","die"],function(a,b){c.fn[b]=function(d,f,e,j){var i,o=0,k,n,r=j||this.selector,
+u=j?this:c(this.context);if(c.isFunction(f)){e=f;f=w}for(d=(d||"").split(" ");(i=d[o++])!=null;){j=O.exec(i);k="";if(j){k=j[0];i=i.replace(O,"")}if(i==="hover")d.push("mouseenter"+k,"mouseleave"+k);else{n=i;if(i==="focus"||i==="blur"){d.push(Ga[i]+k);i+=k}else i=(Ga[i]||i)+k;b==="live"?u.each(function(){c.event.add(this,pa(i,r),{data:f,selector:r,handler:e,origType:i,origHandler:e,preType:n})}):u.unbind(pa(i,r),e)}}return this}});c.each("blur focus focusin focusout load resize scroll unload click dblclick mousedown mouseup mousemove mouseover mouseout mouseenter mouseleave change select submit keydown keypress keyup error".split(" "),
+function(a,b){c.fn[b]=function(d){return d?this.bind(b,d):this.trigger(b)};if(c.attrFn)c.attrFn[b]=true});A.attachEvent&&!A.addEventListener&&A.attachEvent("onunload",function(){for(var a in c.cache)if(c.cache[a].handle)try{c.event.remove(c.cache[a].handle.elem)}catch(b){}});(function(){function a(g){for(var h="",l,m=0;g[m];m++){l=g[m];if(l.nodeType===3||l.nodeType===4)h+=l.nodeValue;else if(l.nodeType!==8)h+=a(l.childNodes)}return h}function b(g,h,l,m,q,p){q=0;for(var v=m.length;q<v;q++){var t=m[q];
+if(t){t=t[g];for(var y=false;t;){if(t.sizcache===l){y=m[t.sizset];break}if(t.nodeType===1&&!p){t.sizcache=l;t.sizset=q}if(t.nodeName.toLowerCase()===h){y=t;break}t=t[g]}m[q]=y}}}function d(g,h,l,m,q,p){q=0;for(var v=m.length;q<v;q++){var t=m[q];if(t){t=t[g];for(var y=false;t;){if(t.sizcache===l){y=m[t.sizset];break}if(t.nodeType===1){if(!p){t.sizcache=l;t.sizset=q}if(typeof h!=="string"){if(t===h){y=true;break}}else if(k.filter(h,[t]).length>0){y=t;break}}t=t[g]}m[q]=y}}}var f=/((?:\((?:\([^()]+\)|[^()]+)+\)|\[(?:\[[^[\]]*\]|['"][^'"]*['"]|[^[\]'"]+)+\]|\\.|[^ >+~,(\[\\]+)+|[>+~])(\s*,\s*)?((?:.|\r|\n)*)/g,
+e=0,j=Object.prototype.toString,i=false,o=true;[0,0].sort(function(){o=false;return 0});var k=function(g,h,l,m){l=l||[];var q=h=h||s;if(h.nodeType!==1&&h.nodeType!==9)return[];if(!g||typeof g!=="string")return l;for(var p=[],v,t,y,S,H=true,M=x(h),I=g;(f.exec(""),v=f.exec(I))!==null;){I=v[3];p.push(v[1]);if(v[2]){S=v[3];break}}if(p.length>1&&r.exec(g))if(p.length===2&&n.relative[p[0]])t=ga(p[0]+p[1],h);else for(t=n.relative[p[0]]?[h]:k(p.shift(),h);p.length;){g=p.shift();if(n.relative[g])g+=p.shift();
+t=ga(g,t)}else{if(!m&&p.length>1&&h.nodeType===9&&!M&&n.match.ID.test(p[0])&&!n.match.ID.test(p[p.length-1])){v=k.find(p.shift(),h,M);h=v.expr?k.filter(v.expr,v.set)[0]:v.set[0]}if(h){v=m?{expr:p.pop(),set:z(m)}:k.find(p.pop(),p.length===1&&(p[0]==="~"||p[0]==="+")&&h.parentNode?h.parentNode:h,M);t=v.expr?k.filter(v.expr,v.set):v.set;if(p.length>0)y=z(t);else H=false;for(;p.length;){var D=p.pop();v=D;if(n.relative[D])v=p.pop();else D="";if(v==null)v=h;n.relative[D](y,v,M)}}else y=[]}y||(y=t);y||k.error(D||
+g);if(j.call(y)==="[object Array]")if(H)if(h&&h.nodeType===1)for(g=0;y[g]!=null;g++){if(y[g]&&(y[g]===true||y[g].nodeType===1&&E(h,y[g])))l.push(t[g])}else for(g=0;y[g]!=null;g++)y[g]&&y[g].nodeType===1&&l.push(t[g]);else l.push.apply(l,y);else z(y,l);if(S){k(S,q,l,m);k.uniqueSort(l)}return l};k.uniqueSort=function(g){if(B){i=o;g.sort(B);if(i)for(var h=1;h<g.length;h++)g[h]===g[h-1]&&g.splice(h--,1)}return g};k.matches=function(g,h){return k(g,null,null,h)};k.find=function(g,h,l){var m,q;if(!g)return[];
+for(var p=0,v=n.order.length;p<v;p++){var t=n.order[p];if(q=n.leftMatch[t].exec(g)){var y=q[1];q.splice(1,1);if(y.substr(y.length-1)!=="\\"){q[1]=(q[1]||"").replace(/\\/g,"");m=n.find[t](q,h,l);if(m!=null){g=g.replace(n.match[t],"");break}}}}m||(m=h.getElementsByTagName("*"));return{set:m,expr:g}};k.filter=function(g,h,l,m){for(var q=g,p=[],v=h,t,y,S=h&&h[0]&&x(h[0]);g&&h.length;){for(var H in n.filter)if((t=n.leftMatch[H].exec(g))!=null&&t[2]){var M=n.filter[H],I,D;D=t[1];y=false;t.splice(1,1);if(D.substr(D.length-
+1)!=="\\"){if(v===p)p=[];if(n.preFilter[H])if(t=n.preFilter[H](t,v,l,p,m,S)){if(t===true)continue}else y=I=true;if(t)for(var U=0;(D=v[U])!=null;U++)if(D){I=M(D,t,U,v);var Ha=m^!!I;if(l&&I!=null)if(Ha)y=true;else v[U]=false;else if(Ha){p.push(D);y=true}}if(I!==w){l||(v=p);g=g.replace(n.match[H],"");if(!y)return[];break}}}if(g===q)if(y==null)k.error(g);else break;q=g}return v};k.error=function(g){throw"Syntax error, unrecognized expression: "+g;};var n=k.selectors={order:["ID","NAME","TAG"],match:{ID:/#((?:[\w\u00c0-\uFFFF-]|\\.)+)/,
+CLASS:/\.((?:[\w\u00c0-\uFFFF-]|\\.)+)/,NAME:/\[name=['"]*((?:[\w\u00c0-\uFFFF-]|\\.)+)['"]*\]/,ATTR:/\[\s*((?:[\w\u00c0-\uFFFF-]|\\.)+)\s*(?:(\S?=)\s*(['"]*)(.*?)\3|)\s*\]/,TAG:/^((?:[\w\u00c0-\uFFFF\*-]|\\.)+)/,CHILD:/:(only|nth|last|first)-child(?:\((even|odd|[\dn+-]*)\))?/,POS:/:(nth|eq|gt|lt|first|last|even|odd)(?:\((\d*)\))?(?=[^-]|$)/,PSEUDO:/:((?:[\w\u00c0-\uFFFF-]|\\.)+)(?:\((['"]?)((?:\([^\)]+\)|[^\(\)]*)+)\2\))?/},leftMatch:{},attrMap:{"class":"className","for":"htmlFor"},attrHandle:{href:function(g){return g.getAttribute("href")}},
+relative:{"+":function(g,h){var l=typeof h==="string",m=l&&!/\W/.test(h);l=l&&!m;if(m)h=h.toLowerCase();m=0;for(var q=g.length,p;m<q;m++)if(p=g[m]){for(;(p=p.previousSibling)&&p.nodeType!==1;);g[m]=l||p&&p.nodeName.toLowerCase()===h?p||false:p===h}l&&k.filter(h,g,true)},">":function(g,h){var l=typeof h==="string";if(l&&!/\W/.test(h)){h=h.toLowerCase();for(var m=0,q=g.length;m<q;m++){var p=g[m];if(p){l=p.parentNode;g[m]=l.nodeName.toLowerCase()===h?l:false}}}else{m=0;for(q=g.length;m<q;m++)if(p=g[m])g[m]=
+l?p.parentNode:p.parentNode===h;l&&k.filter(h,g,true)}},"":function(g,h,l){var m=e++,q=d;if(typeof h==="string"&&!/\W/.test(h)){var p=h=h.toLowerCase();q=b}q("parentNode",h,m,g,p,l)},"~":function(g,h,l){var m=e++,q=d;if(typeof h==="string"&&!/\W/.test(h)){var p=h=h.toLowerCase();q=b}q("previousSibling",h,m,g,p,l)}},find:{ID:function(g,h,l){if(typeof h.getElementById!=="undefined"&&!l)return(g=h.getElementById(g[1]))?[g]:[]},NAME:function(g,h){if(typeof h.getElementsByName!=="undefined"){var l=[];
+h=h.getElementsByName(g[1]);for(var m=0,q=h.length;m<q;m++)h[m].getAttribute("name")===g[1]&&l.push(h[m]);return l.length===0?null:l}},TAG:function(g,h){return h.getElementsByTagName(g[1])}},preFilter:{CLASS:function(g,h,l,m,q,p){g=" "+g[1].replace(/\\/g,"")+" ";if(p)return g;p=0;for(var v;(v=h[p])!=null;p++)if(v)if(q^(v.className&&(" "+v.className+" ").replace(/[\t\n]/g," ").indexOf(g)>=0))l||m.push(v);else if(l)h[p]=false;return false},ID:function(g){return g[1].replace(/\\/g,"")},TAG:function(g){return g[1].toLowerCase()},
+CHILD:function(g){if(g[1]==="nth"){var h=/(-?)(\d*)n((?:\+|-)?\d*)/.exec(g[2]==="even"&&"2n"||g[2]==="odd"&&"2n+1"||!/\D/.test(g[2])&&"0n+"+g[2]||g[2]);g[2]=h[1]+(h[2]||1)-0;g[3]=h[3]-0}g[0]=e++;return g},ATTR:function(g,h,l,m,q,p){h=g[1].replace(/\\/g,"");if(!p&&n.attrMap[h])g[1]=n.attrMap[h];if(g[2]==="~=")g[4]=" "+g[4]+" ";return g},PSEUDO:function(g,h,l,m,q){if(g[1]==="not")if((f.exec(g[3])||"").length>1||/^\w/.test(g[3]))g[3]=k(g[3],null,null,h);else{g=k.filter(g[3],h,l,true^q);l||m.push.apply(m,
+g);return false}else if(n.match.POS.test(g[0])||n.match.CHILD.test(g[0]))return true;return g},POS:function(g){g.unshift(true);return g}},filters:{enabled:function(g){return g.disabled===false&&g.type!=="hidden"},disabled:function(g){return g.disabled===true},checked:function(g){return g.checked===true},selected:function(g){return g.selected===true},parent:function(g){return!!g.firstChild},empty:function(g){return!g.firstChild},has:function(g,h,l){return!!k(l[3],g).length},header:function(g){return/h\d/i.test(g.nodeName)},
+text:function(g){return"text"===g.type},radio:function(g){return"radio"===g.type},checkbox:function(g){return"checkbox"===g.type},file:function(g){return"file"===g.type},password:function(g){return"password"===g.type},submit:function(g){return"submit"===g.type},image:function(g){return"image"===g.type},reset:function(g){return"reset"===g.type},button:function(g){return"button"===g.type||g.nodeName.toLowerCase()==="button"},input:function(g){return/input|select|textarea|button/i.test(g.nodeName)}},
+setFilters:{first:function(g,h){return h===0},last:function(g,h,l,m){return h===m.length-1},even:function(g,h){return h%2===0},odd:function(g,h){return h%2===1},lt:function(g,h,l){return h<l[3]-0},gt:function(g,h,l){return h>l[3]-0},nth:function(g,h,l){return l[3]-0===h},eq:function(g,h,l){return l[3]-0===h}},filter:{PSEUDO:function(g,h,l,m){var q=h[1],p=n.filters[q];if(p)return p(g,l,h,m);else if(q==="contains")return(g.textContent||g.innerText||a([g])||"").indexOf(h[3])>=0;else if(q==="not"){h=
+h[3];l=0;for(m=h.length;l<m;l++)if(h[l]===g)return false;return true}else k.error("Syntax error, unrecognized expression: "+q)},CHILD:function(g,h){var l=h[1],m=g;switch(l){case "only":case "first":for(;m=m.previousSibling;)if(m.nodeType===1)return false;if(l==="first")return true;m=g;case "last":for(;m=m.nextSibling;)if(m.nodeType===1)return false;return true;case "nth":l=h[2];var q=h[3];if(l===1&&q===0)return true;h=h[0];var p=g.parentNode;if(p&&(p.sizcache!==h||!g.nodeIndex)){var v=0;for(m=p.firstChild;m;m=
+m.nextSibling)if(m.nodeType===1)m.nodeIndex=++v;p.sizcache=h}g=g.nodeIndex-q;return l===0?g===0:g%l===0&&g/l>=0}},ID:function(g,h){return g.nodeType===1&&g.getAttribute("id")===h},TAG:function(g,h){return h==="*"&&g.nodeType===1||g.nodeName.toLowerCase()===h},CLASS:function(g,h){return(" "+(g.className||g.getAttribute("class"))+" ").indexOf(h)>-1},ATTR:function(g,h){var l=h[1];g=n.attrHandle[l]?n.attrHandle[l](g):g[l]!=null?g[l]:g.getAttribute(l);l=g+"";var m=h[2];h=h[4];return g==null?m==="!=":m===
+"="?l===h:m==="*="?l.indexOf(h)>=0:m==="~="?(" "+l+" ").indexOf(h)>=0:!h?l&&g!==false:m==="!="?l!==h:m==="^="?l.indexOf(h)===0:m==="$="?l.substr(l.length-h.length)===h:m==="|="?l===h||l.substr(0,h.length+1)===h+"-":false},POS:function(g,h,l,m){var q=n.setFilters[h[2]];if(q)return q(g,l,h,m)}}},r=n.match.POS;for(var u in n.match){n.match[u]=new RegExp(n.match[u].source+/(?![^\[]*\])(?![^\(]*\))/.source);n.leftMatch[u]=new RegExp(/(^(?:.|\r|\n)*?)/.source+n.match[u].source.replace(/\\(\d+)/g,function(g,
+h){return"\\"+(h-0+1)}))}var z=function(g,h){g=Array.prototype.slice.call(g,0);if(h){h.push.apply(h,g);return h}return g};try{Array.prototype.slice.call(s.documentElement.childNodes,0)}catch(C){z=function(g,h){h=h||[];if(j.call(g)==="[object Array]")Array.prototype.push.apply(h,g);else if(typeof g.length==="number")for(var l=0,m=g.length;l<m;l++)h.push(g[l]);else for(l=0;g[l];l++)h.push(g[l]);return h}}var B;if(s.documentElement.compareDocumentPosition)B=function(g,h){if(!g.compareDocumentPosition||
+!h.compareDocumentPosition){if(g==h)i=true;return g.compareDocumentPosition?-1:1}g=g.compareDocumentPosition(h)&4?-1:g===h?0:1;if(g===0)i=true;return g};else if("sourceIndex"in s.documentElement)B=function(g,h){if(!g.sourceIndex||!h.sourceIndex){if(g==h)i=true;return g.sourceIndex?-1:1}g=g.sourceIndex-h.sourceIndex;if(g===0)i=true;return g};else if(s.createRange)B=function(g,h){if(!g.ownerDocument||!h.ownerDocument){if(g==h)i=true;return g.ownerDocument?-1:1}var l=g.ownerDocument.createRange(),m=
+h.ownerDocument.createRange();l.setStart(g,0);l.setEnd(g,0);m.setStart(h,0);m.setEnd(h,0);g=l.compareBoundaryPoints(Range.START_TO_END,m);if(g===0)i=true;return g};(function(){var g=s.createElement("div"),h="script"+(new Date).getTime();g.innerHTML="<a name='"+h+"'/>";var l=s.documentElement;l.insertBefore(g,l.firstChild);if(s.getElementById(h)){n.find.ID=function(m,q,p){if(typeof q.getElementById!=="undefined"&&!p)return(q=q.getElementById(m[1]))?q.id===m[1]||typeof q.getAttributeNode!=="undefined"&&
+q.getAttributeNode("id").nodeValue===m[1]?[q]:w:[]};n.filter.ID=function(m,q){var p=typeof m.getAttributeNode!=="undefined"&&m.getAttributeNode("id");return m.nodeType===1&&p&&p.nodeValue===q}}l.removeChild(g);l=g=null})();(function(){var g=s.createElement("div");g.appendChild(s.createComment(""));if(g.getElementsByTagName("*").length>0)n.find.TAG=function(h,l){l=l.getElementsByTagName(h[1]);if(h[1]==="*"){h=[];for(var m=0;l[m];m++)l[m].nodeType===1&&h.push(l[m]);l=h}return l};g.innerHTML="<a href='#'></a>";
+if(g.firstChild&&typeof g.firstChild.getAttribute!=="undefined"&&g.firstChild.getAttribute("href")!=="#")n.attrHandle.href=function(h){return h.getAttribute("href",2)};g=null})();s.querySelectorAll&&function(){var g=k,h=s.createElement("div");h.innerHTML="<p class='TEST'></p>";if(!(h.querySelectorAll&&h.querySelectorAll(".TEST").length===0)){k=function(m,q,p,v){q=q||s;if(!v&&q.nodeType===9&&!x(q))try{return z(q.querySelectorAll(m),p)}catch(t){}return g(m,q,p,v)};for(var l in g)k[l]=g[l];h=null}}();
+(function(){var g=s.createElement("div");g.innerHTML="<div class='test e'></div><div class='test'></div>";if(!(!g.getElementsByClassName||g.getElementsByClassName("e").length===0)){g.lastChild.className="e";if(g.getElementsByClassName("e").length!==1){n.order.splice(1,0,"CLASS");n.find.CLASS=function(h,l,m){if(typeof l.getElementsByClassName!=="undefined"&&!m)return l.getElementsByClassName(h[1])};g=null}}})();var E=s.compareDocumentPosition?function(g,h){return!!(g.compareDocumentPosition(h)&16)}:
+function(g,h){return g!==h&&(g.contains?g.contains(h):true)},x=function(g){return(g=(g?g.ownerDocument||g:0).documentElement)?g.nodeName!=="HTML":false},ga=function(g,h){var l=[],m="",q;for(h=h.nodeType?[h]:h;q=n.match.PSEUDO.exec(g);){m+=q[0];g=g.replace(n.match.PSEUDO,"")}g=n.relative[g]?g+"*":g;q=0;for(var p=h.length;q<p;q++)k(g,h[q],l);return k.filter(m,l)};c.find=k;c.expr=k.selectors;c.expr[":"]=c.expr.filters;c.unique=k.uniqueSort;c.text=a;c.isXMLDoc=x;c.contains=E})();var eb=/Until$/,fb=/^(?:parents|prevUntil|prevAll)/,
+gb=/,/;R=Array.prototype.slice;var Ia=function(a,b,d){if(c.isFunction(b))return c.grep(a,function(e,j){return!!b.call(e,j,e)===d});else if(b.nodeType)return c.grep(a,function(e){return e===b===d});else if(typeof b==="string"){var f=c.grep(a,function(e){return e.nodeType===1});if(Ua.test(b))return c.filter(b,f,!d);else b=c.filter(b,f)}return c.grep(a,function(e){return c.inArray(e,b)>=0===d})};c.fn.extend({find:function(a){for(var b=this.pushStack("","find",a),d=0,f=0,e=this.length;f<e;f++){d=b.length;
+c.find(a,this[f],b);if(f>0)for(var j=d;j<b.length;j++)for(var i=0;i<d;i++)if(b[i]===b[j]){b.splice(j--,1);break}}return b},has:function(a){var b=c(a);return this.filter(function(){for(var d=0,f=b.length;d<f;d++)if(c.contains(this,b[d]))return true})},not:function(a){return this.pushStack(Ia(this,a,false),"not",a)},filter:function(a){return this.pushStack(Ia(this,a,true),"filter",a)},is:function(a){return!!a&&c.filter(a,this).length>0},closest:function(a,b){if(c.isArray(a)){var d=[],f=this[0],e,j=
+{},i;if(f&&a.length){e=0;for(var o=a.length;e<o;e++){i=a[e];j[i]||(j[i]=c.expr.match.POS.test(i)?c(i,b||this.context):i)}for(;f&&f.ownerDocument&&f!==b;){for(i in j){e=j[i];if(e.jquery?e.index(f)>-1:c(f).is(e)){d.push({selector:i,elem:f});delete j[i]}}f=f.parentNode}}return d}var k=c.expr.match.POS.test(a)?c(a,b||this.context):null;return this.map(function(n,r){for(;r&&r.ownerDocument&&r!==b;){if(k?k.index(r)>-1:c(r).is(a))return r;r=r.parentNode}return null})},index:function(a){if(!a||typeof a===
+"string")return c.inArray(this[0],a?c(a):this.parent().children());return c.inArray(a.jquery?a[0]:a,this)},add:function(a,b){a=typeof a==="string"?c(a,b||this.context):c.makeArray(a);b=c.merge(this.get(),a);return this.pushStack(qa(a[0])||qa(b[0])?b:c.unique(b))},andSelf:function(){return this.add(this.prevObject)}});c.each({parent:function(a){return(a=a.parentNode)&&a.nodeType!==11?a:null},parents:function(a){return c.dir(a,"parentNode")},parentsUntil:function(a,b,d){return c.dir(a,"parentNode",
+d)},next:function(a){return c.nth(a,2,"nextSibling")},prev:function(a){return c.nth(a,2,"previousSibling")},nextAll:function(a){return c.dir(a,"nextSibling")},prevAll:function(a){return c.dir(a,"previousSibling")},nextUntil:function(a,b,d){return c.dir(a,"nextSibling",d)},prevUntil:function(a,b,d){return c.dir(a,"previousSibling",d)},siblings:function(a){return c.sibling(a.parentNode.firstChild,a)},children:function(a){return c.sibling(a.firstChild)},contents:function(a){return c.nodeName(a,"iframe")?
+a.contentDocument||a.contentWindow.document:c.makeArray(a.childNodes)}},function(a,b){c.fn[a]=function(d,f){var e=c.map(this,b,d);eb.test(a)||(f=d);if(f&&typeof f==="string")e=c.filter(f,e);e=this.length>1?c.unique(e):e;if((this.length>1||gb.test(f))&&fb.test(a))e=e.reverse();return this.pushStack(e,a,R.call(arguments).join(","))}});c.extend({filter:function(a,b,d){if(d)a=":not("+a+")";return c.find.matches(a,b)},dir:function(a,b,d){var f=[];for(a=a[b];a&&a.nodeType!==9&&(d===w||a.nodeType!==1||!c(a).is(d));){a.nodeType===
+1&&f.push(a);a=a[b]}return f},nth:function(a,b,d){b=b||1;for(var f=0;a;a=a[d])if(a.nodeType===1&&++f===b)break;return a},sibling:function(a,b){for(var d=[];a;a=a.nextSibling)a.nodeType===1&&a!==b&&d.push(a);return d}});var Ja=/ jQuery\d+="(?:\d+|null)"/g,V=/^\s+/,Ka=/(<([\w:]+)[^>]*?)\/>/g,hb=/^(?:area|br|col|embed|hr|img|input|link|meta|param)$/i,La=/<([\w:]+)/,ib=/<tbody/i,jb=/<|&#?\w+;/,ta=/<script|<object|<embed|<option|<style/i,ua=/checked\s*(?:[^=]|=\s*.checked.)/i,Ma=function(a,b,d){return hb.test(d)?
+a:b+"></"+d+">"},F={option:[1,"<select multiple='multiple'>","</select>"],legend:[1,"<fieldset>","</fieldset>"],thead:[1,"<table>","</table>"],tr:[2,"<table><tbody>","</tbody></table>"],td:[3,"<table><tbody><tr>","</tr></tbody></table>"],col:[2,"<table><tbody></tbody><colgroup>","</colgroup></table>"],area:[1,"<map>","</map>"],_default:[0,"",""]};F.optgroup=F.option;F.tbody=F.tfoot=F.colgroup=F.caption=F.thead;F.th=F.td;if(!c.support.htmlSerialize)F._default=[1,"div<div>","</div>"];c.fn.extend({text:function(a){if(c.isFunction(a))return this.each(function(b){var d=
+c(this);d.text(a.call(this,b,d.text()))});if(typeof a!=="object"&&a!==w)return this.empty().append((this[0]&&this[0].ownerDocument||s).createTextNode(a));return c.text(this)},wrapAll:function(a){if(c.isFunction(a))return this.each(function(d){c(this).wrapAll(a.call(this,d))});if(this[0]){var b=c(a,this[0].ownerDocument).eq(0).clone(true);this[0].parentNode&&b.insertBefore(this[0]);b.map(function(){for(var d=this;d.firstChild&&d.firstChild.nodeType===1;)d=d.firstChild;return d}).append(this)}return this},
+wrapInner:function(a){if(c.isFunction(a))return this.each(function(b){c(this).wrapInner(a.call(this,b))});return this.each(function(){var b=c(this),d=b.contents();d.length?d.wrapAll(a):b.append(a)})},wrap:function(a){return this.each(function(){c(this).wrapAll(a)})},unwrap:function(){return this.parent().each(function(){c.nodeName(this,"body")||c(this).replaceWith(this.childNodes)}).end()},append:function(){return this.domManip(arguments,true,function(a){this.nodeType===1&&this.appendChild(a)})},
+prepend:function(){return this.domManip(arguments,true,function(a){this.nodeType===1&&this.insertBefore(a,this.firstChild)})},before:function(){if(this[0]&&this[0].parentNode)return this.domManip(arguments,false,function(b){this.parentNode.insertBefore(b,this)});else if(arguments.length){var a=c(arguments[0]);a.push.apply(a,this.toArray());return this.pushStack(a,"before",arguments)}},after:function(){if(this[0]&&this[0].parentNode)return this.domManip(arguments,false,function(b){this.parentNode.insertBefore(b,
+this.nextSibling)});else if(arguments.length){var a=this.pushStack(this,"after",arguments);a.push.apply(a,c(arguments[0]).toArray());return a}},remove:function(a,b){for(var d=0,f;(f=this[d])!=null;d++)if(!a||c.filter(a,[f]).length){if(!b&&f.nodeType===1){c.cleanData(f.getElementsByTagName("*"));c.cleanData([f])}f.parentNode&&f.parentNode.removeChild(f)}return this},empty:function(){for(var a=0,b;(b=this[a])!=null;a++)for(b.nodeType===1&&c.cleanData(b.getElementsByTagName("*"));b.firstChild;)b.removeChild(b.firstChild);
+return this},clone:function(a){var b=this.map(function(){if(!c.support.noCloneEvent&&!c.isXMLDoc(this)){var d=this.outerHTML,f=this.ownerDocument;if(!d){d=f.createElement("div");d.appendChild(this.cloneNode(true));d=d.innerHTML}return c.clean([d.replace(Ja,"").replace(/=([^="'>\s]+\/)>/g,'="$1">').replace(V,"")],f)[0]}else return this.cloneNode(true)});if(a===true){ra(this,b);ra(this.find("*"),b.find("*"))}return b},html:function(a){if(a===w)return this[0]&&this[0].nodeType===1?this[0].innerHTML.replace(Ja,
+""):null;else if(typeof a==="string"&&!ta.test(a)&&(c.support.leadingWhitespace||!V.test(a))&&!F[(La.exec(a)||["",""])[1].toLowerCase()]){a=a.replace(Ka,Ma);try{for(var b=0,d=this.length;b<d;b++)if(this[b].nodeType===1){c.cleanData(this[b].getElementsByTagName("*"));this[b].innerHTML=a}}catch(f){this.empty().append(a)}}else c.isFunction(a)?this.each(function(e){var j=c(this),i=j.html();j.empty().append(function(){return a.call(this,e,i)})}):this.empty().append(a);return this},replaceWith:function(a){if(this[0]&&
+this[0].parentNode){if(c.isFunction(a))return this.each(function(b){var d=c(this),f=d.html();d.replaceWith(a.call(this,b,f))});if(typeof a!=="string")a=c(a).detach();return this.each(function(){var b=this.nextSibling,d=this.parentNode;c(this).remove();b?c(b).before(a):c(d).append(a)})}else return this.pushStack(c(c.isFunction(a)?a():a),"replaceWith",a)},detach:function(a){return this.remove(a,true)},domManip:function(a,b,d){function f(u){return c.nodeName(u,"table")?u.getElementsByTagName("tbody")[0]||
+u.appendChild(u.ownerDocument.createElement("tbody")):u}var e,j,i=a[0],o=[],k;if(!c.support.checkClone&&arguments.length===3&&typeof i==="string"&&ua.test(i))return this.each(function(){c(this).domManip(a,b,d,true)});if(c.isFunction(i))return this.each(function(u){var z=c(this);a[0]=i.call(this,u,b?z.html():w);z.domManip(a,b,d)});if(this[0]){e=i&&i.parentNode;e=c.support.parentNode&&e&&e.nodeType===11&&e.childNodes.length===this.length?{fragment:e}:sa(a,this,o);k=e.fragment;if(j=k.childNodes.length===
+1?(k=k.firstChild):k.firstChild){b=b&&c.nodeName(j,"tr");for(var n=0,r=this.length;n<r;n++)d.call(b?f(this[n],j):this[n],n>0||e.cacheable||this.length>1?k.cloneNode(true):k)}o.length&&c.each(o,Qa)}return this}});c.fragments={};c.each({appendTo:"append",prependTo:"prepend",insertBefore:"before",insertAfter:"after",replaceAll:"replaceWith"},function(a,b){c.fn[a]=function(d){var f=[];d=c(d);var e=this.length===1&&this[0].parentNode;if(e&&e.nodeType===11&&e.childNodes.length===1&&d.length===1){d[b](this[0]);
+return this}else{e=0;for(var j=d.length;e<j;e++){var i=(e>0?this.clone(true):this).get();c.fn[b].apply(c(d[e]),i);f=f.concat(i)}return this.pushStack(f,a,d.selector)}}});c.extend({clean:function(a,b,d,f){b=b||s;if(typeof b.createElement==="undefined")b=b.ownerDocument||b[0]&&b[0].ownerDocument||s;for(var e=[],j=0,i;(i=a[j])!=null;j++){if(typeof i==="number")i+="";if(i){if(typeof i==="string"&&!jb.test(i))i=b.createTextNode(i);else if(typeof i==="string"){i=i.replace(Ka,Ma);var o=(La.exec(i)||["",
+""])[1].toLowerCase(),k=F[o]||F._default,n=k[0],r=b.createElement("div");for(r.innerHTML=k[1]+i+k[2];n--;)r=r.lastChild;if(!c.support.tbody){n=ib.test(i);o=o==="table"&&!n?r.firstChild&&r.firstChild.childNodes:k[1]==="<table>"&&!n?r.childNodes:[];for(k=o.length-1;k>=0;--k)c.nodeName(o[k],"tbody")&&!o[k].childNodes.length&&o[k].parentNode.removeChild(o[k])}!c.support.leadingWhitespace&&V.test(i)&&r.insertBefore(b.createTextNode(V.exec(i)[0]),r.firstChild);i=r.childNodes}if(i.nodeType)e.push(i);else e=
+c.merge(e,i)}}if(d)for(j=0;e[j];j++)if(f&&c.nodeName(e[j],"script")&&(!e[j].type||e[j].type.toLowerCase()==="text/javascript"))f.push(e[j].parentNode?e[j].parentNode.removeChild(e[j]):e[j]);else{e[j].nodeType===1&&e.splice.apply(e,[j+1,0].concat(c.makeArray(e[j].getElementsByTagName("script"))));d.appendChild(e[j])}return e},cleanData:function(a){for(var b,d,f=c.cache,e=c.event.special,j=c.support.deleteExpando,i=0,o;(o=a[i])!=null;i++)if(d=o[c.expando]){b=f[d];if(b.events)for(var k in b.events)e[k]?
+c.event.remove(o,k):Ca(o,k,b.handle);if(j)delete o[c.expando];else o.removeAttribute&&o.removeAttribute(c.expando);delete f[d]}}});var kb=/z-?index|font-?weight|opacity|zoom|line-?height/i,Na=/alpha\([^)]*\)/,Oa=/opacity=([^)]*)/,ha=/float/i,ia=/-([a-z])/ig,lb=/([A-Z])/g,mb=/^-?\d+(?:px)?$/i,nb=/^-?\d/,ob={position:"absolute",visibility:"hidden",display:"block"},pb=["Left","Right"],qb=["Top","Bottom"],rb=s.defaultView&&s.defaultView.getComputedStyle,Pa=c.support.cssFloat?"cssFloat":"styleFloat",ja=
+function(a,b){return b.toUpperCase()};c.fn.css=function(a,b){return X(this,a,b,true,function(d,f,e){if(e===w)return c.curCSS(d,f);if(typeof e==="number"&&!kb.test(f))e+="px";c.style(d,f,e)})};c.extend({style:function(a,b,d){if(!a||a.nodeType===3||a.nodeType===8)return w;if((b==="width"||b==="height")&&parseFloat(d)<0)d=w;var f=a.style||a,e=d!==w;if(!c.support.opacity&&b==="opacity"){if(e){f.zoom=1;b=parseInt(d,10)+""==="NaN"?"":"alpha(opacity="+d*100+")";a=f.filter||c.curCSS(a,"filter")||"";f.filter=
+Na.test(a)?a.replace(Na,b):b}return f.filter&&f.filter.indexOf("opacity=")>=0?parseFloat(Oa.exec(f.filter)[1])/100+"":""}if(ha.test(b))b=Pa;b=b.replace(ia,ja);if(e)f[b]=d;return f[b]},css:function(a,b,d,f){if(b==="width"||b==="height"){var e,j=b==="width"?pb:qb;function i(){e=b==="width"?a.offsetWidth:a.offsetHeight;f!=="border"&&c.each(j,function(){f||(e-=parseFloat(c.curCSS(a,"padding"+this,true))||0);if(f==="margin")e+=parseFloat(c.curCSS(a,"margin"+this,true))||0;else e-=parseFloat(c.curCSS(a,
+"border"+this+"Width",true))||0})}a.offsetWidth!==0?i():c.swap(a,ob,i);return Math.max(0,Math.round(e))}return c.curCSS(a,b,d)},curCSS:function(a,b,d){var f,e=a.style;if(!c.support.opacity&&b==="opacity"&&a.currentStyle){f=Oa.test(a.currentStyle.filter||"")?parseFloat(RegExp.$1)/100+"":"";return f===""?"1":f}if(ha.test(b))b=Pa;if(!d&&e&&e[b])f=e[b];else if(rb){if(ha.test(b))b="float";b=b.replace(lb,"-$1").toLowerCase();e=a.ownerDocument.defaultView;if(!e)return null;if(a=e.getComputedStyle(a,null))f=
+a.getPropertyValue(b);if(b==="opacity"&&f==="")f="1"}else if(a.currentStyle){d=b.replace(ia,ja);f=a.currentStyle[b]||a.currentStyle[d];if(!mb.test(f)&&nb.test(f)){b=e.left;var j=a.runtimeStyle.left;a.runtimeStyle.left=a.currentStyle.left;e.left=d==="fontSize"?"1em":f||0;f=e.pixelLeft+"px";e.left=b;a.runtimeStyle.left=j}}return f},swap:function(a,b,d){var f={};for(var e in b){f[e]=a.style[e];a.style[e]=b[e]}d.call(a);for(e in b)a.style[e]=f[e]}});if(c.expr&&c.expr.filters){c.expr.filters.hidden=function(a){var b=
+a.offsetWidth,d=a.offsetHeight,f=a.nodeName.toLowerCase()==="tr";return b===0&&d===0&&!f?true:b>0&&d>0&&!f?false:c.curCSS(a,"display")==="none"};c.expr.filters.visible=function(a){return!c.expr.filters.hidden(a)}}var sb=J(),tb=/<script(.|\s)*?\/script>/gi,ub=/select|textarea/i,vb=/color|date|datetime|email|hidden|month|number|password|range|search|tel|text|time|url|week/i,N=/=\?(&|$)/,ka=/\?/,wb=/(\?|&)_=.*?(&|$)/,xb=/^(\w+:)?\/\/([^\/?#]+)/,yb=/%20/g,zb=c.fn.load;c.fn.extend({load:function(a,b,d){if(typeof a!==
+"string")return zb.call(this,a);else if(!this.length)return this;var f=a.indexOf(" ");if(f>=0){var e=a.slice(f,a.length);a=a.slice(0,f)}f="GET";if(b)if(c.isFunction(b)){d=b;b=null}else if(typeof b==="object"){b=c.param(b,c.ajaxSettings.traditional);f="POST"}var j=this;c.ajax({url:a,type:f,dataType:"html",data:b,complete:function(i,o){if(o==="success"||o==="notmodified")j.html(e?c("<div />").append(i.responseText.replace(tb,"")).find(e):i.responseText);d&&j.each(d,[i.responseText,o,i])}});return this},
+serialize:function(){return c.param(this.serializeArray())},serializeArray:function(){return this.map(function(){return this.elements?c.makeArray(this.elements):this}).filter(function(){return this.name&&!this.disabled&&(this.checked||ub.test(this.nodeName)||vb.test(this.type))}).map(function(a,b){a=c(this).val();return a==null?null:c.isArray(a)?c.map(a,function(d){return{name:b.name,value:d}}):{name:b.name,value:a}}).get()}});c.each("ajaxStart ajaxStop ajaxComplete ajaxError ajaxSuccess ajaxSend".split(" "),
+function(a,b){c.fn[b]=function(d){return this.bind(b,d)}});c.extend({get:function(a,b,d,f){if(c.isFunction(b)){f=f||d;d=b;b=null}return c.ajax({type:"GET",url:a,data:b,success:d,dataType:f})},getScript:function(a,b){return c.get(a,null,b,"script")},getJSON:function(a,b,d){return c.get(a,b,d,"json")},post:function(a,b,d,f){if(c.isFunction(b)){f=f||d;d=b;b={}}return c.ajax({type:"POST",url:a,data:b,success:d,dataType:f})},ajaxSetup:function(a){c.extend(c.ajaxSettings,a)},ajaxSettings:{url:location.href,
+global:true,type:"GET",contentType:"application/x-www-form-urlencoded",processData:true,async:true,xhr:A.XMLHttpRequest&&(A.location.protocol!=="file:"||!A.ActiveXObject)?function(){return new A.XMLHttpRequest}:function(){try{return new A.ActiveXObject("Microsoft.XMLHTTP")}catch(a){}},accepts:{xml:"application/xml, text/xml",html:"text/html",script:"text/javascript, application/javascript",json:"application/json, text/javascript",text:"text/plain",_default:"*/*"}},lastModified:{},etag:{},ajax:function(a){function b(){e.success&&
+e.success.call(k,o,i,x);e.global&&f("ajaxSuccess",[x,e])}function d(){e.complete&&e.complete.call(k,x,i);e.global&&f("ajaxComplete",[x,e]);e.global&&!--c.active&&c.event.trigger("ajaxStop")}function f(q,p){(e.context?c(e.context):c.event).trigger(q,p)}var e=c.extend(true,{},c.ajaxSettings,a),j,i,o,k=a&&a.context||e,n=e.type.toUpperCase();if(e.data&&e.processData&&typeof e.data!=="string")e.data=c.param(e.data,e.traditional);if(e.dataType==="jsonp"){if(n==="GET")N.test(e.url)||(e.url+=(ka.test(e.url)?
+"&":"?")+(e.jsonp||"callback")+"=?");else if(!e.data||!N.test(e.data))e.data=(e.data?e.data+"&":"")+(e.jsonp||"callback")+"=?";e.dataType="json"}if(e.dataType==="json"&&(e.data&&N.test(e.data)||N.test(e.url))){j=e.jsonpCallback||"jsonp"+sb++;if(e.data)e.data=(e.data+"").replace(N,"="+j+"$1");e.url=e.url.replace(N,"="+j+"$1");e.dataType="script";A[j]=A[j]||function(q){o=q;b();d();A[j]=w;try{delete A[j]}catch(p){}z&&z.removeChild(C)}}if(e.dataType==="script"&&e.cache===null)e.cache=false;if(e.cache===
+false&&n==="GET"){var r=J(),u=e.url.replace(wb,"$1_="+r+"$2");e.url=u+(u===e.url?(ka.test(e.url)?"&":"?")+"_="+r:"")}if(e.data&&n==="GET")e.url+=(ka.test(e.url)?"&":"?")+e.data;e.global&&!c.active++&&c.event.trigger("ajaxStart");r=(r=xb.exec(e.url))&&(r[1]&&r[1]!==location.protocol||r[2]!==location.host);if(e.dataType==="script"&&n==="GET"&&r){var z=s.getElementsByTagName("head")[0]||s.documentElement,C=s.createElement("script");C.src=e.url;if(e.scriptCharset)C.charset=e.scriptCharset;if(!j){var B=
+false;C.onload=C.onreadystatechange=function(){if(!B&&(!this.readyState||this.readyState==="loaded"||this.readyState==="complete")){B=true;b();d();C.onload=C.onreadystatechange=null;z&&C.parentNode&&z.removeChild(C)}}}z.insertBefore(C,z.firstChild);return w}var E=false,x=e.xhr();if(x){e.username?x.open(n,e.url,e.async,e.username,e.password):x.open(n,e.url,e.async);try{if(e.data||a&&a.contentType)x.setRequestHeader("Content-Type",e.contentType);if(e.ifModified){c.lastModified[e.url]&&x.setRequestHeader("If-Modified-Since",
+c.lastModified[e.url]);c.etag[e.url]&&x.setRequestHeader("If-None-Match",c.etag[e.url])}r||x.setRequestHeader("X-Requested-With","XMLHttpRequest");x.setRequestHeader("Accept",e.dataType&&e.accepts[e.dataType]?e.accepts[e.dataType]+", */*":e.accepts._default)}catch(ga){}if(e.beforeSend&&e.beforeSend.call(k,x,e)===false){e.global&&!--c.active&&c.event.trigger("ajaxStop");x.abort();return false}e.global&&f("ajaxSend",[x,e]);var g=x.onreadystatechange=function(q){if(!x||x.readyState===0||q==="abort"){E||
+d();E=true;if(x)x.onreadystatechange=c.noop}else if(!E&&x&&(x.readyState===4||q==="timeout")){E=true;x.onreadystatechange=c.noop;i=q==="timeout"?"timeout":!c.httpSuccess(x)?"error":e.ifModified&&c.httpNotModified(x,e.url)?"notmodified":"success";var p;if(i==="success")try{o=c.httpData(x,e.dataType,e)}catch(v){i="parsererror";p=v}if(i==="success"||i==="notmodified")j||b();else c.handleError(e,x,i,p);d();q==="timeout"&&x.abort();if(e.async)x=null}};try{var h=x.abort;x.abort=function(){x&&h.call(x);
+g("abort")}}catch(l){}e.async&&e.timeout>0&&setTimeout(function(){x&&!E&&g("timeout")},e.timeout);try{x.send(n==="POST"||n==="PUT"||n==="DELETE"?e.data:null)}catch(m){c.handleError(e,x,null,m);d()}e.async||g();return x}},handleError:function(a,b,d,f){if(a.error)a.error.call(a.context||a,b,d,f);if(a.global)(a.context?c(a.context):c.event).trigger("ajaxError",[b,a,f])},active:0,httpSuccess:function(a){try{return!a.status&&location.protocol==="file:"||a.status>=200&&a.status<300||a.status===304||a.status===
+1223||a.status===0}catch(b){}return false},httpNotModified:function(a,b){var d=a.getResponseHeader("Last-Modified"),f=a.getResponseHeader("Etag");if(d)c.lastModified[b]=d;if(f)c.etag[b]=f;return a.status===304||a.status===0},httpData:function(a,b,d){var f=a.getResponseHeader("content-type")||"",e=b==="xml"||!b&&f.indexOf("xml")>=0;a=e?a.responseXML:a.responseText;e&&a.documentElement.nodeName==="parsererror"&&c.error("parsererror");if(d&&d.dataFilter)a=d.dataFilter(a,b);if(typeof a==="string")if(b===
+"json"||!b&&f.indexOf("json")>=0)a=c.parseJSON(a);else if(b==="script"||!b&&f.indexOf("javascript")>=0)c.globalEval(a);return a},param:function(a,b){function d(i,o){if(c.isArray(o))c.each(o,function(k,n){b||/\[\]$/.test(i)?f(i,n):d(i+"["+(typeof n==="object"||c.isArray(n)?k:"")+"]",n)});else!b&&o!=null&&typeof o==="object"?c.each(o,function(k,n){d(i+"["+k+"]",n)}):f(i,o)}function f(i,o){o=c.isFunction(o)?o():o;e[e.length]=encodeURIComponent(i)+"="+encodeURIComponent(o)}var e=[];if(b===w)b=c.ajaxSettings.traditional;
+if(c.isArray(a)||a.jquery)c.each(a,function(){f(this.name,this.value)});else for(var j in a)d(j,a[j]);return e.join("&").replace(yb,"+")}});var la={},Ab=/toggle|show|hide/,Bb=/^([+-]=)?([\d+-.]+)(.*)$/,W,va=[["height","marginTop","marginBottom","paddingTop","paddingBottom"],["width","marginLeft","marginRight","paddingLeft","paddingRight"],["opacity"]];c.fn.extend({show:function(a,b){if(a||a===0)return this.animate(K("show",3),a,b);else{a=0;for(b=this.length;a<b;a++){var d=c.data(this[a],"olddisplay");
+this[a].style.display=d||"";if(c.css(this[a],"display")==="none"){d=this[a].nodeName;var f;if(la[d])f=la[d];else{var e=c("<"+d+" />").appendTo("body");f=e.css("display");if(f==="none")f="block";e.remove();la[d]=f}c.data(this[a],"olddisplay",f)}}a=0;for(b=this.length;a<b;a++)this[a].style.display=c.data(this[a],"olddisplay")||"";return this}},hide:function(a,b){if(a||a===0)return this.animate(K("hide",3),a,b);else{a=0;for(b=this.length;a<b;a++){var d=c.data(this[a],"olddisplay");!d&&d!=="none"&&c.data(this[a],
+"olddisplay",c.css(this[a],"display"))}a=0;for(b=this.length;a<b;a++)this[a].style.display="none";return this}},_toggle:c.fn.toggle,toggle:function(a,b){var d=typeof a==="boolean";if(c.isFunction(a)&&c.isFunction(b))this._toggle.apply(this,arguments);else a==null||d?this.each(function(){var f=d?a:c(this).is(":hidden");c(this)[f?"show":"hide"]()}):this.animate(K("toggle",3),a,b);return this},fadeTo:function(a,b,d){return this.filter(":hidden").css("opacity",0).show().end().animate({opacity:b},a,d)},
+animate:function(a,b,d,f){var e=c.speed(b,d,f);if(c.isEmptyObject(a))return this.each(e.complete);return this[e.queue===false?"each":"queue"](function(){var j=c.extend({},e),i,o=this.nodeType===1&&c(this).is(":hidden"),k=this;for(i in a){var n=i.replace(ia,ja);if(i!==n){a[n]=a[i];delete a[i];i=n}if(a[i]==="hide"&&o||a[i]==="show"&&!o)return j.complete.call(this);if((i==="height"||i==="width")&&this.style){j.display=c.css(this,"display");j.overflow=this.style.overflow}if(c.isArray(a[i])){(j.specialEasing=
+j.specialEasing||{})[i]=a[i][1];a[i]=a[i][0]}}if(j.overflow!=null)this.style.overflow="hidden";j.curAnim=c.extend({},a);c.each(a,function(r,u){var z=new c.fx(k,j,r);if(Ab.test(u))z[u==="toggle"?o?"show":"hide":u](a);else{var C=Bb.exec(u),B=z.cur(true)||0;if(C){u=parseFloat(C[2]);var E=C[3]||"px";if(E!=="px"){k.style[r]=(u||1)+E;B=(u||1)/z.cur(true)*B;k.style[r]=B+E}if(C[1])u=(C[1]==="-="?-1:1)*u+B;z.custom(B,u,E)}else z.custom(B,u,"")}});return true})},stop:function(a,b){var d=c.timers;a&&this.queue([]);
+this.each(function(){for(var f=d.length-1;f>=0;f--)if(d[f].elem===this){b&&d[f](true);d.splice(f,1)}});b||this.dequeue();return this}});c.each({slideDown:K("show",1),slideUp:K("hide",1),slideToggle:K("toggle",1),fadeIn:{opacity:"show"},fadeOut:{opacity:"hide"}},function(a,b){c.fn[a]=function(d,f){return this.animate(b,d,f)}});c.extend({speed:function(a,b,d){var f=a&&typeof a==="object"?a:{complete:d||!d&&b||c.isFunction(a)&&a,duration:a,easing:d&&b||b&&!c.isFunction(b)&&b};f.duration=c.fx.off?0:typeof f.duration===
+"number"?f.duration:c.fx.speeds[f.duration]||c.fx.speeds._default;f.old=f.complete;f.complete=function(){f.queue!==false&&c(this).dequeue();c.isFunction(f.old)&&f.old.call(this)};return f},easing:{linear:function(a,b,d,f){return d+f*a},swing:function(a,b,d,f){return(-Math.cos(a*Math.PI)/2+0.5)*f+d}},timers:[],fx:function(a,b,d){this.options=b;this.elem=a;this.prop=d;if(!b.orig)b.orig={}}});c.fx.prototype={update:function(){this.options.step&&this.options.step.call(this.elem,this.now,this);(c.fx.step[this.prop]||
+c.fx.step._default)(this);if((this.prop==="height"||this.prop==="width")&&this.elem.style)this.elem.style.display="block"},cur:function(a){if(this.elem[this.prop]!=null&&(!this.elem.style||this.elem.style[this.prop]==null))return this.elem[this.prop];return(a=parseFloat(c.css(this.elem,this.prop,a)))&&a>-10000?a:parseFloat(c.curCSS(this.elem,this.prop))||0},custom:function(a,b,d){function f(j){return e.step(j)}this.startTime=J();this.start=a;this.end=b;this.unit=d||this.unit||"px";this.now=this.start;
+this.pos=this.state=0;var e=this;f.elem=this.elem;if(f()&&c.timers.push(f)&&!W)W=setInterval(c.fx.tick,13)},show:function(){this.options.orig[this.prop]=c.style(this.elem,this.prop);this.options.show=true;this.custom(this.prop==="width"||this.prop==="height"?1:0,this.cur());c(this.elem).show()},hide:function(){this.options.orig[this.prop]=c.style(this.elem,this.prop);this.options.hide=true;this.custom(this.cur(),0)},step:function(a){var b=J(),d=true;if(a||b>=this.options.duration+this.startTime){this.now=
+this.end;this.pos=this.state=1;this.update();this.options.curAnim[this.prop]=true;for(var f in this.options.curAnim)if(this.options.curAnim[f]!==true)d=false;if(d){if(this.options.display!=null){this.elem.style.overflow=this.options.overflow;a=c.data(this.elem,"olddisplay");this.elem.style.display=a?a:this.options.display;if(c.css(this.elem,"display")==="none")this.elem.style.display="block"}this.options.hide&&c(this.elem).hide();if(this.options.hide||this.options.show)for(var e in this.options.curAnim)c.style(this.elem,
+e,this.options.orig[e]);this.options.complete.call(this.elem)}return false}else{e=b-this.startTime;this.state=e/this.options.duration;a=this.options.easing||(c.easing.swing?"swing":"linear");this.pos=c.easing[this.options.specialEasing&&this.options.specialEasing[this.prop]||a](this.state,e,0,1,this.options.duration);this.now=this.start+(this.end-this.start)*this.pos;this.update()}return true}};c.extend(c.fx,{tick:function(){for(var a=c.timers,b=0;b<a.length;b++)a[b]()||a.splice(b--,1);a.length||
+c.fx.stop()},stop:function(){clearInterval(W);W=null},speeds:{slow:600,fast:200,_default:400},step:{opacity:function(a){c.style(a.elem,"opacity",a.now)},_default:function(a){if(a.elem.style&&a.elem.style[a.prop]!=null)a.elem.style[a.prop]=(a.prop==="width"||a.prop==="height"?Math.max(0,a.now):a.now)+a.unit;else a.elem[a.prop]=a.now}}});if(c.expr&&c.expr.filters)c.expr.filters.animated=function(a){return c.grep(c.timers,function(b){return a===b.elem}).length};c.fn.offset="getBoundingClientRect"in s.documentElement?
+function(a){var b=this[0];if(a)return this.each(function(e){c.offset.setOffset(this,a,e)});if(!b||!b.ownerDocument)return null;if(b===b.ownerDocument.body)return c.offset.bodyOffset(b);var d=b.getBoundingClientRect(),f=b.ownerDocument;b=f.body;f=f.documentElement;return{top:d.top+(self.pageYOffset||c.support.boxModel&&f.scrollTop||b.scrollTop)-(f.clientTop||b.clientTop||0),left:d.left+(self.pageXOffset||c.support.boxModel&&f.scrollLeft||b.scrollLeft)-(f.clientLeft||b.clientLeft||0)}}:function(a){var b=
+this[0];if(a)return this.each(function(r){c.offset.setOffset(this,a,r)});if(!b||!b.ownerDocument)return null;if(b===b.ownerDocument.body)return c.offset.bodyOffset(b);c.offset.initialize();var d=b.offsetParent,f=b,e=b.ownerDocument,j,i=e.documentElement,o=e.body;f=(e=e.defaultView)?e.getComputedStyle(b,null):b.currentStyle;for(var k=b.offsetTop,n=b.offsetLeft;(b=b.parentNode)&&b!==o&&b!==i;){if(c.offset.supportsFixedPosition&&f.position==="fixed")break;j=e?e.getComputedStyle(b,null):b.currentStyle;
+k-=b.scrollTop;n-=b.scrollLeft;if(b===d){k+=b.offsetTop;n+=b.offsetLeft;if(c.offset.doesNotAddBorder&&!(c.offset.doesAddBorderForTableAndCells&&/^t(able|d|h)$/i.test(b.nodeName))){k+=parseFloat(j.borderTopWidth)||0;n+=parseFloat(j.borderLeftWidth)||0}f=d;d=b.offsetParent}if(c.offset.subtractsBorderForOverflowNotVisible&&j.overflow!=="visible"){k+=parseFloat(j.borderTopWidth)||0;n+=parseFloat(j.borderLeftWidth)||0}f=j}if(f.position==="relative"||f.position==="static"){k+=o.offsetTop;n+=o.offsetLeft}if(c.offset.supportsFixedPosition&&
+f.position==="fixed"){k+=Math.max(i.scrollTop,o.scrollTop);n+=Math.max(i.scrollLeft,o.scrollLeft)}return{top:k,left:n}};c.offset={initialize:function(){var a=s.body,b=s.createElement("div"),d,f,e,j=parseFloat(c.curCSS(a,"marginTop",true))||0;c.extend(b.style,{position:"absolute",top:0,left:0,margin:0,border:0,width:"1px",height:"1px",visibility:"hidden"});b.innerHTML="<div style='position:absolute;top:0;left:0;margin:0;border:5px solid #000;padding:0;width:1px;height:1px;'><div></div></div><table style='position:absolute;top:0;left:0;margin:0;border:5px solid #000;padding:0;width:1px;height:1px;' cellpadding='0' cellspacing='0'><tr><td></td></tr></table>";
+a.insertBefore(b,a.firstChild);d=b.firstChild;f=d.firstChild;e=d.nextSibling.firstChild.firstChild;this.doesNotAddBorder=f.offsetTop!==5;this.doesAddBorderForTableAndCells=e.offsetTop===5;f.style.position="fixed";f.style.top="20px";this.supportsFixedPosition=f.offsetTop===20||f.offsetTop===15;f.style.position=f.style.top="";d.style.overflow="hidden";d.style.position="relative";this.subtractsBorderForOverflowNotVisible=f.offsetTop===-5;this.doesNotIncludeMarginInBodyOffset=a.offsetTop!==j;a.removeChild(b);
+c.offset.initialize=c.noop},bodyOffset:function(a){var b=a.offsetTop,d=a.offsetLeft;c.offset.initialize();if(c.offset.doesNotIncludeMarginInBodyOffset){b+=parseFloat(c.curCSS(a,"marginTop",true))||0;d+=parseFloat(c.curCSS(a,"marginLeft",true))||0}return{top:b,left:d}},setOffset:function(a,b,d){if(/static/.test(c.curCSS(a,"position")))a.style.position="relative";var f=c(a),e=f.offset(),j=parseInt(c.curCSS(a,"top",true),10)||0,i=parseInt(c.curCSS(a,"left",true),10)||0;if(c.isFunction(b))b=b.call(a,
+d,e);d={top:b.top-e.top+j,left:b.left-e.left+i};"using"in b?b.using.call(a,d):f.css(d)}};c.fn.extend({position:function(){if(!this[0])return null;var a=this[0],b=this.offsetParent(),d=this.offset(),f=/^body|html$/i.test(b[0].nodeName)?{top:0,left:0}:b.offset();d.top-=parseFloat(c.curCSS(a,"marginTop",true))||0;d.left-=parseFloat(c.curCSS(a,"marginLeft",true))||0;f.top+=parseFloat(c.curCSS(b[0],"borderTopWidth",true))||0;f.left+=parseFloat(c.curCSS(b[0],"borderLeftWidth",true))||0;return{top:d.top-
+f.top,left:d.left-f.left}},offsetParent:function(){return this.map(function(){for(var a=this.offsetParent||s.body;a&&!/^body|html$/i.test(a.nodeName)&&c.css(a,"position")==="static";)a=a.offsetParent;return a})}});c.each(["Left","Top"],function(a,b){var d="scroll"+b;c.fn[d]=function(f){var e=this[0],j;if(!e)return null;if(f!==w)return this.each(function(){if(j=wa(this))j.scrollTo(!a?f:c(j).scrollLeft(),a?f:c(j).scrollTop());else this[d]=f});else return(j=wa(e))?"pageXOffset"in j?j[a?"pageYOffset":
+"pageXOffset"]:c.support.boxModel&&j.document.documentElement[d]||j.document.body[d]:e[d]}});c.each(["Height","Width"],function(a,b){var d=b.toLowerCase();c.fn["inner"+b]=function(){return this[0]?c.css(this[0],d,false,"padding"):null};c.fn["outer"+b]=function(f){return this[0]?c.css(this[0],d,false,f?"margin":"border"):null};c.fn[d]=function(f){var e=this[0];if(!e)return f==null?null:this;if(c.isFunction(f))return this.each(function(j){var i=c(this);i[d](f.call(this,j,i[d]()))});return"scrollTo"in
+e&&e.document?e.document.compatMode==="CSS1Compat"&&e.document.documentElement["client"+b]||e.document.body["client"+b]:e.nodeType===9?Math.max(e.documentElement["client"+b],e.body["scroll"+b],e.documentElement["scroll"+b],e.body["offset"+b],e.documentElement["offset"+b]):f===w?c.css(e,d):this.css(d,typeof f==="string"?f:f+"px")}});A.jQuery=A.$=c})(window);
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/minus.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/minus.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/minus.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/plus.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/plus.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/plus.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/pygments.css
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/pygments.css?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_static/pygments.css (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_static/pygments.css Thu May 10 06:54:16 2018
@@ -0,0 +1,62 @@
+.highlight .hll { background-color: #ffffcc }
+.highlight { background: #f0f0f0; }
+.highlight .c { color: #60a0b0; font-style: italic } /* Comment */
+.highlight .err { border: 1px solid #FF0000 } /* Error */
+.highlight .k { color: #007020; font-weight: bold } /* Keyword */
+.highlight .o { color: #666666 } /* Operator */
+.highlight .cm { color: #60a0b0; font-style: italic } /* Comment.Multiline */
+.highlight .cp { color: #007020 } /* Comment.Preproc */
+.highlight .c1 { color: #60a0b0; font-style: italic } /* Comment.Single */
+.highlight .cs { color: #60a0b0; background-color: #fff0f0 } /* Comment.Special */
+.highlight .gd { color: #A00000 } /* Generic.Deleted */
+.highlight .ge { font-style: italic } /* Generic.Emph */
+.highlight .gr { color: #FF0000 } /* Generic.Error */
+.highlight .gh { color: #000080; font-weight: bold } /* Generic.Heading */
+.highlight .gi { color: #00A000 } /* Generic.Inserted */
+.highlight .go { color: #808080 } /* Generic.Output */
+.highlight .gp { color: #c65d09; font-weight: bold } /* Generic.Prompt */
+.highlight .gs { font-weight: bold } /* Generic.Strong */
+.highlight .gu { color: #800080; font-weight: bold } /* Generic.Subheading */
+.highlight .gt { color: #0040D0 } /* Generic.Traceback */
+.highlight .kc { color: #007020; font-weight: bold } /* Keyword.Constant */
+.highlight .kd { color: #007020; font-weight: bold } /* Keyword.Declaration */
+.highlight .kn { color: #007020; font-weight: bold } /* Keyword.Namespace */
+.highlight .kp { color: #007020 } /* Keyword.Pseudo */
+.highlight .kr { color: #007020; font-weight: bold } /* Keyword.Reserved */
+.highlight .kt { color: #902000 } /* Keyword.Type */
+.highlight .m { color: #40a070 } /* Literal.Number */
+.highlight .s { color: #4070a0 } /* Literal.String */
+.highlight .na { color: #4070a0 } /* Name.Attribute */
+.highlight .nb { color: #007020 } /* Name.Builtin */
+.highlight .nc { color: #0e84b5; font-weight: bold } /* Name.Class */
+.highlight .no { color: #60add5 } /* Name.Constant */
+.highlight .nd { color: #555555; font-weight: bold } /* Name.Decorator */
+.highlight .ni { color: #d55537; font-weight: bold } /* Name.Entity */
+.highlight .ne { color: #007020 } /* Name.Exception */
+.highlight .nf { color: #06287e } /* Name.Function */
+.highlight .nl { color: #002070; font-weight: bold } /* Name.Label */
+.highlight .nn { color: #0e84b5; font-weight: bold } /* Name.Namespace */
+.highlight .nt { color: #062873; font-weight: bold } /* Name.Tag */
+.highlight .nv { color: #bb60d5 } /* Name.Variable */
+.highlight .ow { color: #007020; font-weight: bold } /* Operator.Word */
+.highlight .w { color: #bbbbbb } /* Text.Whitespace */
+.highlight .mf { color: #40a070 } /* Literal.Number.Float */
+.highlight .mh { color: #40a070 } /* Literal.Number.Hex */
+.highlight .mi { color: #40a070 } /* Literal.Number.Integer */
+.highlight .mo { color: #40a070 } /* Literal.Number.Oct */
+.highlight .sb { color: #4070a0 } /* Literal.String.Backtick */
+.highlight .sc { color: #4070a0 } /* Literal.String.Char */
+.highlight .sd { color: #4070a0; font-style: italic } /* Literal.String.Doc */
+.highlight .s2 { color: #4070a0 } /* Literal.String.Double */
+.highlight .se { color: #4070a0; font-weight: bold } /* Literal.String.Escape */
+.highlight .sh { color: #4070a0 } /* Literal.String.Heredoc */
+.highlight .si { color: #70a0d0; font-style: italic } /* Literal.String.Interpol */
+.highlight .sx { color: #c65d09 } /* Literal.String.Other */
+.highlight .sr { color: #235388 } /* Literal.String.Regex */
+.highlight .s1 { color: #4070a0 } /* Literal.String.Single */
+.highlight .ss { color: #517918 } /* Literal.String.Symbol */
+.highlight .bp { color: #007020 } /* Name.Builtin.Pseudo */
+.highlight .vc { color: #bb60d5 } /* Name.Variable.Class */
+.highlight .vg { color: #bb60d5 } /* Name.Variable.Global */
+.highlight .vi { color: #bb60d5 } /* Name.Variable.Instance */
+.highlight .il { color: #40a070 } /* Literal.Number.Integer.Long */
\ No newline at end of file
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/searchtools.js
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/searchtools.js?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_static/searchtools.js (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_static/searchtools.js Thu May 10 06:54:16 2018
@@ -0,0 +1,560 @@
+/*
+ * searchtools.js_t
+ * ~~~~~~~~~~~~~~~~
+ *
+ * Sphinx JavaScript utilties for the full-text search.
+ *
+ * :copyright: Copyright 2007-2011 by the Sphinx team, see AUTHORS.
+ * :license: BSD, see LICENSE for details.
+ *
+ */
+
+/**
+ * helper function to return a node containing the
+ * search summary for a given text. keywords is a list
+ * of stemmed words, hlwords is the list of normal, unstemmed
+ * words. the first one is used to find the occurance, the
+ * latter for highlighting it.
+ */
+
+jQuery.makeSearchSummary = function(text, keywords, hlwords) {
+ var textLower = text.toLowerCase();
+ var start = 0;
+ $.each(keywords, function() {
+ var i = textLower.indexOf(this.toLowerCase());
+ if (i > -1)
+ start = i;
+ });
+ start = Math.max(start - 120, 0);
+ var excerpt = ((start > 0) ? '...' : '') +
+ $.trim(text.substr(start, 240)) +
+ ((start + 240 - text.length) ? '...' : '');
+ var rv = $('<div class="context"></div>').text(excerpt);
+ $.each(hlwords, function() {
+ rv = rv.highlightText(this, 'highlighted');
+ });
+ return rv;
+}
+
+
+/**
+ * Porter Stemmer
+ */
+var Stemmer = function() {
+
+ var step2list = {
+ ational: 'ate',
+ tional: 'tion',
+ enci: 'ence',
+ anci: 'ance',
+ izer: 'ize',
+ bli: 'ble',
+ alli: 'al',
+ entli: 'ent',
+ eli: 'e',
+ ousli: 'ous',
+ ization: 'ize',
+ ation: 'ate',
+ ator: 'ate',
+ alism: 'al',
+ iveness: 'ive',
+ fulness: 'ful',
+ ousness: 'ous',
+ aliti: 'al',
+ iviti: 'ive',
+ biliti: 'ble',
+ logi: 'log'
+ };
+
+ var step3list = {
+ icate: 'ic',
+ ative: '',
+ alize: 'al',
+ iciti: 'ic',
+ ical: 'ic',
+ ful: '',
+ ness: ''
+ };
+
+ var c = "[^aeiou]"; // consonant
+ var v = "[aeiouy]"; // vowel
+ var C = c + "[^aeiouy]*"; // consonant sequence
+ var V = v + "[aeiou]*"; // vowel sequence
+
+ var mgr0 = "^(" + C + ")?" + V + C; // [C]VC... is m>0
+ var meq1 = "^(" + C + ")?" + V + C + "(" + V + ")?$"; // [C]VC[V] is m=1
+ var mgr1 = "^(" + C + ")?" + V + C + V + C; // [C]VCVC... is m>1
+ var s_v = "^(" + C + ")?" + v; // vowel in stem
+
+ this.stemWord = function (w) {
+ var stem;
+ var suffix;
+ var firstch;
+ var origword = w;
+
+ if (w.length < 3)
+ return w;
+
+ var re;
+ var re2;
+ var re3;
+ var re4;
+
+ firstch = w.substr(0,1);
+ if (firstch == "y")
+ w = firstch.toUpperCase() + w.substr(1);
+
+ // Step 1a
+ re = /^(.+?)(ss|i)es$/;
+ re2 = /^(.+?)([^s])s$/;
+
+ if (re.test(w))
+ w = w.replace(re,"$1$2");
+ else if (re2.test(w))
+ w = w.replace(re2,"$1$2");
+
+ // Step 1b
+ re = /^(.+?)eed$/;
+ re2 = /^(.+?)(ed|ing)$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ re = new RegExp(mgr0);
+ if (re.test(fp[1])) {
+ re = /.$/;
+ w = w.replace(re,"");
+ }
+ }
+ else if (re2.test(w)) {
+ var fp = re2.exec(w);
+ stem = fp[1];
+ re2 = new RegExp(s_v);
+ if (re2.test(stem)) {
+ w = stem;
+ re2 = /(at|bl|iz)$/;
+ re3 = new RegExp("([^aeiouylsz])\\1$");
+ re4 = new RegExp("^" + C + v + "[^aeiouwxy]$");
+ if (re2.test(w))
+ w = w + "e";
+ else if (re3.test(w)) {
+ re = /.$/;
+ w = w.replace(re,"");
+ }
+ else if (re4.test(w))
+ w = w + "e";
+ }
+ }
+
+ // Step 1c
+ re = /^(.+?)y$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ re = new RegExp(s_v);
+ if (re.test(stem))
+ w = stem + "i";
+ }
+
+ // Step 2
+ re = /^(.+?)(ational|tional|enci|anci|izer|bli|alli|entli|eli|ousli|ization|ation|ator|alism|iveness|fulness|ousness|aliti|iviti|biliti|logi)$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ suffix = fp[2];
+ re = new RegExp(mgr0);
+ if (re.test(stem))
+ w = stem + step2list[suffix];
+ }
+
+ // Step 3
+ re = /^(.+?)(icate|ative|alize|iciti|ical|ful|ness)$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ suffix = fp[2];
+ re = new RegExp(mgr0);
+ if (re.test(stem))
+ w = stem + step3list[suffix];
+ }
+
+ // Step 4
+ re = /^(.+?)(al|ance|ence|er|ic|able|ible|ant|ement|ment|ent|ou|ism|ate|iti|ous|ive|ize)$/;
+ re2 = /^(.+?)(s|t)(ion)$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ re = new RegExp(mgr1);
+ if (re.test(stem))
+ w = stem;
+ }
+ else if (re2.test(w)) {
+ var fp = re2.exec(w);
+ stem = fp[1] + fp[2];
+ re2 = new RegExp(mgr1);
+ if (re2.test(stem))
+ w = stem;
+ }
+
+ // Step 5
+ re = /^(.+?)e$/;
+ if (re.test(w)) {
+ var fp = re.exec(w);
+ stem = fp[1];
+ re = new RegExp(mgr1);
+ re2 = new RegExp(meq1);
+ re3 = new RegExp("^" + C + v + "[^aeiouwxy]$");
+ if (re.test(stem) || (re2.test(stem) && !(re3.test(stem))))
+ w = stem;
+ }
+ re = /ll$/;
+ re2 = new RegExp(mgr1);
+ if (re.test(w) && re2.test(w)) {
+ re = /.$/;
+ w = w.replace(re,"");
+ }
+
+ // and turn initial Y back to y
+ if (firstch == "y")
+ w = firstch.toLowerCase() + w.substr(1);
+ return w;
+ }
+}
+
+
+/**
+ * Search Module
+ */
+var Search = {
+
+ _index : null,
+ _queued_query : null,
+ _pulse_status : -1,
+
+ init : function() {
+ var params = $.getQueryParameters();
+ if (params.q) {
+ var query = params.q[0];
+ $('input[name="q"]')[0].value = query;
+ this.performSearch(query);
+ }
+ },
+
+ loadIndex : function(url) {
+ $.ajax({type: "GET", url: url, data: null, success: null,
+ dataType: "script", cache: true});
+ },
+
+ setIndex : function(index) {
+ var q;
+ this._index = index;
+ if ((q = this._queued_query) !== null) {
+ this._queued_query = null;
+ Search.query(q);
+ }
+ },
+
+ hasIndex : function() {
+ return this._index !== null;
+ },
+
+ deferQuery : function(query) {
+ this._queued_query = query;
+ },
+
+ stopPulse : function() {
+ this._pulse_status = 0;
+ },
+
+ startPulse : function() {
+ if (this._pulse_status >= 0)
+ return;
+ function pulse() {
+ Search._pulse_status = (Search._pulse_status + 1) % 4;
+ var dotString = '';
+ for (var i = 0; i < Search._pulse_status; i++)
+ dotString += '.';
+ Search.dots.text(dotString);
+ if (Search._pulse_status > -1)
+ window.setTimeout(pulse, 500);
+ };
+ pulse();
+ },
+
+ /**
+ * perform a search for something
+ */
+ performSearch : function(query) {
+ // create the required interface elements
+ this.out = $('#search-results');
+ this.title = $('<h2>' + _('Searching') + '</h2>').appendTo(this.out);
+ this.dots = $('<span></span>').appendTo(this.title);
+ this.status = $('<p style="display: none"></p>').appendTo(this.out);
+ this.output = $('<ul class="search"/>').appendTo(this.out);
+
+ $('#search-progress').text(_('Preparing search...'));
+ this.startPulse();
+
+ // index already loaded, the browser was quick!
+ if (this.hasIndex())
+ this.query(query);
+ else
+ this.deferQuery(query);
+ },
+
+ query : function(query) {
+ var stopwords = ["and","then","into","it","as","are","in","if","for","no","there","their","was","is","be","to","that","but","they","not","such","with","by","a","on","these","of","will","this","near","the","or","at"];
+
+ // Stem the searchterms and add them to the correct list
+ var stemmer = new Stemmer();
+ var searchterms = [];
+ var excluded = [];
+ var hlterms = [];
+ var tmp = query.split(/\s+/);
+ var objectterms = [];
+ for (var i = 0; i < tmp.length; i++) {
+ if (tmp[i] != "") {
+ objectterms.push(tmp[i].toLowerCase());
+ }
+
+ if ($u.indexOf(stopwords, tmp[i]) != -1 || tmp[i].match(/^\d+$/) ||
+ tmp[i] == "") {
+ // skip this "word"
+ continue;
+ }
+ // stem the word
+ var word = stemmer.stemWord(tmp[i]).toLowerCase();
+ // select the correct list
+ if (word[0] == '-') {
+ var toAppend = excluded;
+ word = word.substr(1);
+ }
+ else {
+ var toAppend = searchterms;
+ hlterms.push(tmp[i].toLowerCase());
+ }
+ // only add if not already in the list
+ if (!$.contains(toAppend, word))
+ toAppend.push(word);
+ };
+ var highlightstring = '?highlight=' + $.urlencode(hlterms.join(" "));
+
+ // console.debug('SEARCH: searching for:');
+ // console.info('required: ', searchterms);
+ // console.info('excluded: ', excluded);
+
+ // prepare search
+ var filenames = this._index.filenames;
+ var titles = this._index.titles;
+ var terms = this._index.terms;
+ var fileMap = {};
+ var files = null;
+ // different result priorities
+ var importantResults = [];
+ var objectResults = [];
+ var regularResults = [];
+ var unimportantResults = [];
+ $('#search-progress').empty();
+
+ // lookup as object
+ for (var i = 0; i < objectterms.length; i++) {
+ var others = [].concat(objectterms.slice(0,i),
+ objectterms.slice(i+1, objectterms.length))
+ var results = this.performObjectSearch(objectterms[i], others);
+ // Assume first word is most likely to be the object,
+ // other words more likely to be in description.
+ // Therefore put matches for earlier words first.
+ // (Results are eventually used in reverse order).
+ objectResults = results[0].concat(objectResults);
+ importantResults = results[1].concat(importantResults);
+ unimportantResults = results[2].concat(unimportantResults);
+ }
+
+ // perform the search on the required terms
+ for (var i = 0; i < searchterms.length; i++) {
+ var word = searchterms[i];
+ // no match but word was a required one
+ if ((files = terms[word]) == null)
+ break;
+ if (files.length == undefined) {
+ files = [files];
+ }
+ // create the mapping
+ for (var j = 0; j < files.length; j++) {
+ var file = files[j];
+ if (file in fileMap)
+ fileMap[file].push(word);
+ else
+ fileMap[file] = [word];
+ }
+ }
+
+ // now check if the files don't contain excluded terms
+ for (var file in fileMap) {
+ var valid = true;
+
+ // check if all requirements are matched
+ if (fileMap[file].length != searchterms.length)
+ continue;
+
+ // ensure that none of the excluded terms is in the
+ // search result.
+ for (var i = 0; i < excluded.length; i++) {
+ if (terms[excluded[i]] == file ||
+ $.contains(terms[excluded[i]] || [], file)) {
+ valid = false;
+ break;
+ }
+ }
+
+ // if we have still a valid result we can add it
+ // to the result list
+ if (valid)
+ regularResults.push([filenames[file], titles[file], '', null]);
+ }
+
+ // delete unused variables in order to not waste
+ // memory until list is retrieved completely
+ delete filenames, titles, terms;
+
+ // now sort the regular results descending by title
+ regularResults.sort(function(a, b) {
+ var left = a[1].toLowerCase();
+ var right = b[1].toLowerCase();
+ return (left > right) ? -1 : ((left < right) ? 1 : 0);
+ });
+
+ // combine all results
+ var results = unimportantResults.concat(regularResults)
+ .concat(objectResults).concat(importantResults);
+
+ // print the results
+ var resultCount = results.length;
+ function displayNextItem() {
+ // results left, load the summary and display it
+ if (results.length) {
+ var item = results.pop();
+ var listItem = $('<li style="display:none"></li>');
+ if (DOCUMENTATION_OPTIONS.FILE_SUFFIX == '') {
+ // dirhtml builder
+ var dirname = item[0] + '/';
+ if (dirname.match(/\/index\/$/)) {
+ dirname = dirname.substring(0, dirname.length-6);
+ } else if (dirname == 'index/') {
+ dirname = '';
+ }
+ listItem.append($('<a/>').attr('href',
+ DOCUMENTATION_OPTIONS.URL_ROOT + dirname +
+ highlightstring + item[2]).html(item[1]));
+ } else {
+ // normal html builders
+ listItem.append($('<a/>').attr('href',
+ item[0] + DOCUMENTATION_OPTIONS.FILE_SUFFIX +
+ highlightstring + item[2]).html(item[1]));
+ }
+ if (item[3]) {
+ listItem.append($('<span> (' + item[3] + ')</span>'));
+ Search.output.append(listItem);
+ listItem.slideDown(5, function() {
+ displayNextItem();
+ });
+ } else if (DOCUMENTATION_OPTIONS.HAS_SOURCE) {
+ $.get(DOCUMENTATION_OPTIONS.URL_ROOT + '_sources/' +
+ item[0] + '.txt', function(data) {
+ if (data != '') {
+ listItem.append($.makeSearchSummary(data, searchterms, hlterms));
+ Search.output.append(listItem);
+ }
+ listItem.slideDown(5, function() {
+ displayNextItem();
+ });
+ }, "text");
+ } else {
+ // no source available, just display title
+ Search.output.append(listItem);
+ listItem.slideDown(5, function() {
+ displayNextItem();
+ });
+ }
+ }
+ // search finished, update title and status message
+ else {
+ Search.stopPulse();
+ Search.title.text(_('Search Results'));
+ if (!resultCount)
+ Search.status.text(_('Your search did not match any documents. Please make sure that all words are spelled correctly and that you\'ve selected enough categories.'));
+ else
+ Search.status.text(_('Search finished, found %s page(s) matching the search query.').replace('%s', resultCount));
+ Search.status.fadeIn(500);
+ }
+ }
+ displayNextItem();
+ },
+
+ performObjectSearch : function(object, otherterms) {
+ var filenames = this._index.filenames;
+ var objects = this._index.objects;
+ var objnames = this._index.objnames;
+ var titles = this._index.titles;
+
+ var importantResults = [];
+ var objectResults = [];
+ var unimportantResults = [];
+
+ for (var prefix in objects) {
+ for (var name in objects[prefix]) {
+ var fullname = (prefix ? prefix + '.' : '') + name;
+ if (fullname.toLowerCase().indexOf(object) > -1) {
+ var match = objects[prefix][name];
+ var objname = objnames[match[1]][2];
+ var title = titles[match[0]];
+ // If more than one term searched for, we require other words to be
+ // found in the name/title/description
+ if (otherterms.length > 0) {
+ var haystack = (prefix + ' ' + name + ' ' +
+ objname + ' ' + title).toLowerCase();
+ var allfound = true;
+ for (var i = 0; i < otherterms.length; i++) {
+ if (haystack.indexOf(otherterms[i]) == -1) {
+ allfound = false;
+ break;
+ }
+ }
+ if (!allfound) {
+ continue;
+ }
+ }
+ var descr = objname + _(', in ') + title;
+ anchor = match[3];
+ if (anchor == '')
+ anchor = fullname;
+ else if (anchor == '-')
+ anchor = objnames[match[1]][1] + '-' + fullname;
+ result = [filenames[match[0]], fullname, '#'+anchor, descr];
+ switch (match[2]) {
+ case 1: objectResults.push(result); break;
+ case 0: importantResults.push(result); break;
+ case 2: unimportantResults.push(result); break;
+ }
+ }
+ }
+ }
+
+ // sort results descending
+ objectResults.sort(function(a, b) {
+ return (a[1] > b[1]) ? -1 : ((a[1] < b[1]) ? 1 : 0);
+ });
+
+ importantResults.sort(function(a, b) {
+ return (a[1] > b[1]) ? -1 : ((a[1] < b[1]) ? 1 : 0);
+ });
+
+ unimportantResults.sort(function(a, b) {
+ return (a[1] > b[1]) ? -1 : ((a[1] < b[1]) ? 1 : 0);
+ });
+
+ return [importantResults, objectResults, unimportantResults]
+ }
+}
+
+$(document).ready(function() {
+ Search.init();
+});
\ No newline at end of file
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/underscore.js
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/underscore.js?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_static/underscore.js (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_static/underscore.js Thu May 10 06:54:16 2018
@@ -0,0 +1,23 @@
+// Underscore.js 0.5.5
+// (c) 2009 Jeremy Ashkenas, DocumentCloud Inc.
+// Underscore is freely distributable under the terms of the MIT license.
+// Portions of Underscore are inspired by or borrowed from Prototype.js,
+// Oliver Steele's Functional, and John Resig's Micro-Templating.
+// For all details and documentation:
+// http://documentcloud.github.com/underscore/
+(function(){var j=this,n=j._,i=function(a){this._wrapped=a},m=typeof StopIteration!=="undefined"?StopIteration:"__break__",b=j._=function(a){return new i(a)};if(typeof exports!=="undefined")exports._=b;var k=Array.prototype.slice,o=Array.prototype.unshift,p=Object.prototype.toString,q=Object.prototype.hasOwnProperty,r=Object.prototype.propertyIsEnumerable;b.VERSION="0.5.5";b.each=function(a,c,d){try{if(a.forEach)a.forEach(c,d);else if(b.isArray(a)||b.isArguments(a))for(var e=0,f=a.length;e<f;e++)c.call(d,
+a[e],e,a);else{var g=b.keys(a);f=g.length;for(e=0;e<f;e++)c.call(d,a[g[e]],g[e],a)}}catch(h){if(h!=m)throw h;}return a};b.map=function(a,c,d){if(a&&b.isFunction(a.map))return a.map(c,d);var e=[];b.each(a,function(f,g,h){e.push(c.call(d,f,g,h))});return e};b.reduce=function(a,c,d,e){if(a&&b.isFunction(a.reduce))return a.reduce(b.bind(d,e),c);b.each(a,function(f,g,h){c=d.call(e,c,f,g,h)});return c};b.reduceRight=function(a,c,d,e){if(a&&b.isFunction(a.reduceRight))return a.reduceRight(b.bind(d,e),c);
+var f=b.clone(b.toArray(a)).reverse();b.each(f,function(g,h){c=d.call(e,c,g,h,a)});return c};b.detect=function(a,c,d){var e;b.each(a,function(f,g,h){if(c.call(d,f,g,h)){e=f;b.breakLoop()}});return e};b.select=function(a,c,d){if(a&&b.isFunction(a.filter))return a.filter(c,d);var e=[];b.each(a,function(f,g,h){c.call(d,f,g,h)&&e.push(f)});return e};b.reject=function(a,c,d){var e=[];b.each(a,function(f,g,h){!c.call(d,f,g,h)&&e.push(f)});return e};b.all=function(a,c,d){c=c||b.identity;if(a&&b.isFunction(a.every))return a.every(c,
+d);var e=true;b.each(a,function(f,g,h){(e=e&&c.call(d,f,g,h))||b.breakLoop()});return e};b.any=function(a,c,d){c=c||b.identity;if(a&&b.isFunction(a.some))return a.some(c,d);var e=false;b.each(a,function(f,g,h){if(e=c.call(d,f,g,h))b.breakLoop()});return e};b.include=function(a,c){if(b.isArray(a))return b.indexOf(a,c)!=-1;var d=false;b.each(a,function(e){if(d=e===c)b.breakLoop()});return d};b.invoke=function(a,c){var d=b.rest(arguments,2);return b.map(a,function(e){return(c?e[c]:e).apply(e,d)})};b.pluck=
+function(a,c){return b.map(a,function(d){return d[c]})};b.max=function(a,c,d){if(!c&&b.isArray(a))return Math.max.apply(Math,a);var e={computed:-Infinity};b.each(a,function(f,g,h){g=c?c.call(d,f,g,h):f;g>=e.computed&&(e={value:f,computed:g})});return e.value};b.min=function(a,c,d){if(!c&&b.isArray(a))return Math.min.apply(Math,a);var e={computed:Infinity};b.each(a,function(f,g,h){g=c?c.call(d,f,g,h):f;g<e.computed&&(e={value:f,computed:g})});return e.value};b.sortBy=function(a,c,d){return b.pluck(b.map(a,
+function(e,f,g){return{value:e,criteria:c.call(d,e,f,g)}}).sort(function(e,f){e=e.criteria;f=f.criteria;return e<f?-1:e>f?1:0}),"value")};b.sortedIndex=function(a,c,d){d=d||b.identity;for(var e=0,f=a.length;e<f;){var g=e+f>>1;d(a[g])<d(c)?(e=g+1):(f=g)}return e};b.toArray=function(a){if(!a)return[];if(a.toArray)return a.toArray();if(b.isArray(a))return a;if(b.isArguments(a))return k.call(a);return b.values(a)};b.size=function(a){return b.toArray(a).length};b.first=function(a,c,d){return c&&!d?k.call(a,
+0,c):a[0]};b.rest=function(a,c,d){return k.call(a,b.isUndefined(c)||d?1:c)};b.last=function(a){return a[a.length-1]};b.compact=function(a){return b.select(a,function(c){return!!c})};b.flatten=function(a){return b.reduce(a,[],function(c,d){if(b.isArray(d))return c.concat(b.flatten(d));c.push(d);return c})};b.without=function(a){var c=b.rest(arguments);return b.select(a,function(d){return!b.include(c,d)})};b.uniq=function(a,c){return b.reduce(a,[],function(d,e,f){if(0==f||(c===true?b.last(d)!=e:!b.include(d,
+e)))d.push(e);return d})};b.intersect=function(a){var c=b.rest(arguments);return b.select(b.uniq(a),function(d){return b.all(c,function(e){return b.indexOf(e,d)>=0})})};b.zip=function(){for(var a=b.toArray(arguments),c=b.max(b.pluck(a,"length")),d=new Array(c),e=0;e<c;e++)d[e]=b.pluck(a,String(e));return d};b.indexOf=function(a,c){if(a.indexOf)return a.indexOf(c);for(var d=0,e=a.length;d<e;d++)if(a[d]===c)return d;return-1};b.lastIndexOf=function(a,c){if(a.lastIndexOf)return a.lastIndexOf(c);for(var d=
+a.length;d--;)if(a[d]===c)return d;return-1};b.range=function(a,c,d){var e=b.toArray(arguments),f=e.length<=1;a=f?0:e[0];c=f?e[0]:e[1];d=e[2]||1;e=Math.ceil((c-a)/d);if(e<=0)return[];e=new Array(e);f=a;for(var g=0;1;f+=d){if((d>0?f-c:c-f)>=0)return e;e[g++]=f}};b.bind=function(a,c){var d=b.rest(arguments,2);return function(){return a.apply(c||j,d.concat(b.toArray(arguments)))}};b.bindAll=function(a){var c=b.rest(arguments);if(c.length==0)c=b.functions(a);b.each(c,function(d){a[d]=b.bind(a[d],a)});
+return a};b.delay=function(a,c){var d=b.rest(arguments,2);return setTimeout(function(){return a.apply(a,d)},c)};b.defer=function(a){return b.delay.apply(b,[a,1].concat(b.rest(arguments)))};b.wrap=function(a,c){return function(){var d=[a].concat(b.toArray(arguments));return c.apply(c,d)}};b.compose=function(){var a=b.toArray(arguments);return function(){for(var c=b.toArray(arguments),d=a.length-1;d>=0;d--)c=[a[d].apply(this,c)];return c[0]}};b.keys=function(a){if(b.isArray(a))return b.range(0,a.length);
+var c=[];for(var d in a)q.call(a,d)&&c.push(d);return c};b.values=function(a){return b.map(a,b.identity)};b.functions=function(a){return b.select(b.keys(a),function(c){return b.isFunction(a[c])}).sort()};b.extend=function(a,c){for(var d in c)a[d]=c[d];return a};b.clone=function(a){if(b.isArray(a))return a.slice(0);return b.extend({},a)};b.tap=function(a,c){c(a);return a};b.isEqual=function(a,c){if(a===c)return true;var d=typeof a;if(d!=typeof c)return false;if(a==c)return true;if(!a&&c||a&&!c)return false;
+if(a.isEqual)return a.isEqual(c);if(b.isDate(a)&&b.isDate(c))return a.getTime()===c.getTime();if(b.isNaN(a)&&b.isNaN(c))return true;if(b.isRegExp(a)&&b.isRegExp(c))return a.source===c.source&&a.global===c.global&&a.ignoreCase===c.ignoreCase&&a.multiline===c.multiline;if(d!=="object")return false;if(a.length&&a.length!==c.length)return false;d=b.keys(a);var e=b.keys(c);if(d.length!=e.length)return false;for(var f in a)if(!b.isEqual(a[f],c[f]))return false;return true};b.isEmpty=function(a){return b.keys(a).length==
+0};b.isElement=function(a){return!!(a&&a.nodeType==1)};b.isArray=function(a){return!!(a&&a.concat&&a.unshift)};b.isArguments=function(a){return a&&b.isNumber(a.length)&&!b.isArray(a)&&!r.call(a,"length")};b.isFunction=function(a){return!!(a&&a.constructor&&a.call&&a.apply)};b.isString=function(a){return!!(a===""||a&&a.charCodeAt&&a.substr)};b.isNumber=function(a){return p.call(a)==="[object Number]"};b.isDate=function(a){return!!(a&&a.getTimezoneOffset&&a.setUTCFullYear)};b.isRegExp=function(a){return!!(a&&
+a.test&&a.exec&&(a.ignoreCase||a.ignoreCase===false))};b.isNaN=function(a){return b.isNumber(a)&&isNaN(a)};b.isNull=function(a){return a===null};b.isUndefined=function(a){return typeof a=="undefined"};b.noConflict=function(){j._=n;return this};b.identity=function(a){return a};b.breakLoop=function(){throw m;};var s=0;b.uniqueId=function(a){var c=s++;return a?a+c:c};b.template=function(a,c){a=new Function("obj","var p=[],print=function(){p.push.apply(p,arguments);};with(obj){p.push('"+a.replace(/[\r\t\n]/g,
+" ").replace(/'(?=[^%]*%>)/g,"\t").split("'").join("\\'").split("\t").join("'").replace(/<%=(.+?)%>/g,"',$1,'").split("<%").join("');").split("%>").join("p.push('")+"');}return p.join('');");return c?a(c):a};b.forEach=b.each;b.foldl=b.inject=b.reduce;b.foldr=b.reduceRight;b.filter=b.select;b.every=b.all;b.some=b.any;b.head=b.first;b.tail=b.rest;b.methods=b.functions;var l=function(a,c){return c?b(a).chain():a};b.each(b.functions(b),function(a){var c=b[a];i.prototype[a]=function(){var d=b.toArray(arguments);
+o.call(d,this._wrapped);return l(c.apply(b,d),this._chain)}});b.each(["pop","push","reverse","shift","sort","splice","unshift"],function(a){var c=Array.prototype[a];i.prototype[a]=function(){c.apply(this._wrapped,arguments);return l(this._wrapped,this._chain)}});b.each(["concat","join","slice"],function(a){var c=Array.prototype[a];i.prototype[a]=function(){return l(c.apply(this._wrapped,arguments),this._chain)}});i.prototype.chain=function(){this._chain=true;return this};i.prototype.value=function(){return this._wrapped}})();
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/up-pressed.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/up-pressed.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/up-pressed.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/up.png
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/up.png?rev=331981&view=auto
==============================================================================
Binary file - no diff available.
Propchange: www-releases/trunk/5.0.2/tools/clang/docs/_static/up.png
------------------------------------------------------------------------------
svn:mime-type = image/png
Added: www-releases/trunk/5.0.2/tools/clang/docs/_static/websupport.js
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/5.0.2/tools/clang/docs/_static/websupport.js?rev=331981&view=auto
==============================================================================
--- www-releases/trunk/5.0.2/tools/clang/docs/_static/websupport.js (added)
+++ www-releases/trunk/5.0.2/tools/clang/docs/_static/websupport.js Thu May 10 06:54:16 2018
@@ -0,0 +1,808 @@
+/*
+ * websupport.js
+ * ~~~~~~~~~~~~~
+ *
+ * sphinx.websupport utilties for all documentation.
+ *
+ * :copyright: Copyright 2007-2011 by the Sphinx team, see AUTHORS.
+ * :license: BSD, see LICENSE for details.
+ *
+ */
+
+(function($) {
+ $.fn.autogrow = function() {
+ return this.each(function() {
+ var textarea = this;
+
+ $.fn.autogrow.resize(textarea);
+
+ $(textarea)
+ .focus(function() {
+ textarea.interval = setInterval(function() {
+ $.fn.autogrow.resize(textarea);
+ }, 500);
+ })
+ .blur(function() {
+ clearInterval(textarea.interval);
+ });
+ });
+ };
+
+ $.fn.autogrow.resize = function(textarea) {
+ var lineHeight = parseInt($(textarea).css('line-height'), 10);
+ var lines = textarea.value.split('\n');
+ var columns = textarea.cols;
+ var lineCount = 0;
+ $.each(lines, function() {
+ lineCount += Math.ceil(this.length / columns) || 1;
+ });
+ var height = lineHeight * (lineCount + 1);
+ $(textarea).css('height', height);
+ };
+})(jQuery);
+
+(function($) {
+ var comp, by;
+
+ function init() {
+ initEvents();
+ initComparator();
+ }
+
+ function initEvents() {
+ $('a.comment-close').live("click", function(event) {
+ event.preventDefault();
+ hide($(this).attr('id').substring(2));
+ });
+ $('a.vote').live("click", function(event) {
+ event.preventDefault();
+ handleVote($(this));
+ });
+ $('a.reply').live("click", function(event) {
+ event.preventDefault();
+ openReply($(this).attr('id').substring(2));
+ });
+ $('a.close-reply').live("click", function(event) {
+ event.preventDefault();
+ closeReply($(this).attr('id').substring(2));
+ });
+ $('a.sort-option').live("click", function(event) {
+ event.preventDefault();
+ handleReSort($(this));
+ });
+ $('a.show-proposal').live("click", function(event) {
+ event.preventDefault();
+ showProposal($(this).attr('id').substring(2));
+ });
+ $('a.hide-proposal').live("click", function(event) {
+ event.preventDefault();
+ hideProposal($(this).attr('id').substring(2));
+ });
+ $('a.show-propose-change').live("click", function(event) {
+ event.preventDefault();
+ showProposeChange($(this).attr('id').substring(2));
+ });
+ $('a.hide-propose-change').live("click", function(event) {
+ event.preventDefault();
+ hideProposeChange($(this).attr('id').substring(2));
+ });
+ $('a.accept-comment').live("click", function(event) {
+ event.preventDefault();
+ acceptComment($(this).attr('id').substring(2));
+ });
+ $('a.delete-comment').live("click", function(event) {
+ event.preventDefault();
+ deleteComment($(this).attr('id').substring(2));
+ });
+ $('a.comment-markup').live("click", function(event) {
+ event.preventDefault();
+ toggleCommentMarkupBox($(this).attr('id').substring(2));
+ });
+ }
+
+ /**
+ * Set comp, which is a comparator function used for sorting and
+ * inserting comments into the list.
+ */
+ function setComparator() {
+ // If the first three letters are "asc", sort in ascending order
+ // and remove the prefix.
+ if (by.substring(0,3) == 'asc') {
+ var i = by.substring(3);
+ comp = function(a, b) { return a[i] - b[i]; };
+ } else {
+ // Otherwise sort in descending order.
+ comp = function(a, b) { return b[by] - a[by]; };
+ }
+
+ // Reset link styles and format the selected sort option.
+ $('a.sel').attr('href', '#').removeClass('sel');
+ $('a.by' + by).removeAttr('href').addClass('sel');
+ }
+
+ /**
+ * Create a comp function. If the user has preferences stored in
+ * the sortBy cookie, use those, otherwise use the default.
+ */
+ function initComparator() {
+ by = 'rating'; // Default to sort by rating.
+ // If the sortBy cookie is set, use that instead.
+ if (document.cookie.length > 0) {
+ var start = document.cookie.indexOf('sortBy=');
+ if (start != -1) {
+ start = start + 7;
+ var end = document.cookie.indexOf(";", start);
+ if (end == -1) {
+ end = document.cookie.length;
+ by = unescape(document.cookie.substring(start, end));
+ }
+ }
+ }
+ setComparator();
+ }
+
+ /**
+ * Show a comment div.
+ */
+ function show(id) {
+ $('#ao' + id).hide();
+ $('#ah' + id).show();
+ var context = $.extend({id: id}, opts);
+ var popup = $(renderTemplate(popupTemplate, context)).hide();
+ popup.find('textarea[name="proposal"]').hide();
+ popup.find('a.by' + by).addClass('sel');
+ var form = popup.find('#cf' + id);
+ form.submit(function(event) {
+ event.preventDefault();
+ addComment(form);
+ });
+ $('#s' + id).after(popup);
+ popup.slideDown('fast', function() {
+ getComments(id);
+ });
+ }
+
+ /**
+ * Hide a comment div.
+ */
+ function hide(id) {
+ $('#ah' + id).hide();
+ $('#ao' + id).show();
+ var div = $('#sc' + id);
+ div.slideUp('fast', function() {
+ div.remove();
+ });
+ }
+
+ /**
+ * Perform an ajax request to get comments for a node
+ * and insert the comments into the comments tree.
+ */
+ function getComments(id) {
+ $.ajax({
+ type: 'GET',
+ url: opts.getCommentsURL,
+ data: {node: id},
+ success: function(data, textStatus, request) {
+ var ul = $('#cl' + id);
+ var speed = 100;
+ $('#cf' + id)
+ .find('textarea[name="proposal"]')
+ .data('source', data.source);
+
+ if (data.comments.length === 0) {
+ ul.html('<li>No comments yet.</li>');
+ ul.data('empty', true);
+ } else {
+ // If there are comments, sort them and put them in the list.
+ var comments = sortComments(data.comments);
+ speed = data.comments.length * 100;
+ appendComments(comments, ul);
+ ul.data('empty', false);
+ }
+ $('#cn' + id).slideUp(speed + 200);
+ ul.slideDown(speed);
+ },
+ error: function(request, textStatus, error) {
+ showError('Oops, there was a problem retrieving the comments.');
+ },
+ dataType: 'json'
+ });
+ }
+
+ /**
+ * Add a comment via ajax and insert the comment into the comment tree.
+ */
+ function addComment(form) {
+ var node_id = form.find('input[name="node"]').val();
+ var parent_id = form.find('input[name="parent"]').val();
+ var text = form.find('textarea[name="comment"]').val();
+ var proposal = form.find('textarea[name="proposal"]').val();
+
+ if (text == '') {
+ showError('Please enter a comment.');
+ return;
+ }
+
+ // Disable the form that is being submitted.
+ form.find('textarea,input').attr('disabled', 'disabled');
+
+ // Send the comment to the server.
+ $.ajax({
+ type: "POST",
+ url: opts.addCommentURL,
+ dataType: 'json',
+ data: {
+ node: node_id,
+ parent: parent_id,
+ text: text,
+ proposal: proposal
+ },
+ success: function(data, textStatus, error) {
+ // Reset the form.
+ if (node_id) {
+ hideProposeChange(node_id);
+ }
+ form.find('textarea')
+ .val('')
+ .add(form.find('input'))
+ .removeAttr('disabled');
+ var ul = $('#cl' + (node_id || parent_id));
+ if (ul.data('empty')) {
+ $(ul).empty();
+ ul.data('empty', false);
+ }
+ insertComment(data.comment);
+ var ao = $('#ao' + node_id);
+ ao.find('img').attr({'src': opts.commentBrightImage});
+ if (node_id) {
+ // if this was a "root" comment, remove the commenting box
+ // (the user can get it back by reopening the comment popup)
+ $('#ca' + node_id).slideUp();
+ }
+ },
+ error: function(request, textStatus, error) {
+ form.find('textarea,input').removeAttr('disabled');
+ showError('Oops, there was a problem adding the comment.');
+ }
+ });
+ }
+
+ /**
+ * Recursively append comments to the main comment list and children
+ * lists, creating the comment tree.
+ */
+ function appendComments(comments, ul) {
+ $.each(comments, function() {
+ var div = createCommentDiv(this);
+ ul.append($(document.createElement('li')).html(div));
+ appendComments(this.children, div.find('ul.comment-children'));
+ // To avoid stagnating data, don't store the comments children in data.
+ this.children = null;
+ div.data('comment', this);
+ });
+ }
+
+ /**
+ * After adding a new comment, it must be inserted in the correct
+ * location in the comment tree.
+ */
+ function insertComment(comment) {
+ var div = createCommentDiv(comment);
+
+ // To avoid stagnating data, don't store the comments children in data.
+ comment.children = null;
+ div.data('comment', comment);
+
+ var ul = $('#cl' + (comment.node || comment.parent));
+ var siblings = getChildren(ul);
+
+ var li = $(document.createElement('li'));
+ li.hide();
+
+ // Determine where in the parents children list to insert this comment.
+ for(i=0; i < siblings.length; i++) {
+ if (comp(comment, siblings[i]) <= 0) {
+ $('#cd' + siblings[i].id)
+ .parent()
+ .before(li.html(div));
+ li.slideDown('fast');
+ return;
+ }
+ }
+
+ // If we get here, this comment rates lower than all the others,
+ // or it is the only comment in the list.
+ ul.append(li.html(div));
+ li.slideDown('fast');
+ }
+
+ function acceptComment(id) {
+ $.ajax({
+ type: 'POST',
+ url: opts.acceptCommentURL,
+ data: {id: id},
+ success: function(data, textStatus, request) {
+ $('#cm' + id).fadeOut('fast');
+ $('#cd' + id).removeClass('moderate');
+ },
+ error: function(request, textStatus, error) {
+ showError('Oops, there was a problem accepting the comment.');
+ }
+ });
+ }
+
+ function deleteComment(id) {
+ $.ajax({
+ type: 'POST',
+ url: opts.deleteCommentURL,
+ data: {id: id},
+ success: function(data, textStatus, request) {
+ var div = $('#cd' + id);
+ if (data == 'delete') {
+ // Moderator mode: remove the comment and all children immediately
+ div.slideUp('fast', function() {
+ div.remove();
+ });
+ return;
+ }
+ // User mode: only mark the comment as deleted
+ div
+ .find('span.user-id:first')
+ .text('[deleted]').end()
+ .find('div.comment-text:first')
+ .text('[deleted]').end()
+ .find('#cm' + id + ', #dc' + id + ', #ac' + id + ', #rc' + id +
+ ', #sp' + id + ', #hp' + id + ', #cr' + id + ', #rl' + id)
+ .remove();
+ var comment = div.data('comment');
+ comment.username = '[deleted]';
+ comment.text = '[deleted]';
+ div.data('comment', comment);
+ },
+ error: function(request, textStatus, error) {
+ showError('Oops, there was a problem deleting the comment.');
+ }
+ });
+ }
+
+ function showProposal(id) {
+ $('#sp' + id).hide();
+ $('#hp' + id).show();
+ $('#pr' + id).slideDown('fast');
+ }
+
+ function hideProposal(id) {
+ $('#hp' + id).hide();
+ $('#sp' + id).show();
+ $('#pr' + id).slideUp('fast');
+ }
+
+ function showProposeChange(id) {
+ $('#pc' + id).hide();
+ $('#hc' + id).show();
+ var textarea = $('#pt' + id);
+ textarea.val(textarea.data('source'));
+ $.fn.autogrow.resize(textarea[0]);
+ textarea.slideDown('fast');
+ }
+
+ function hideProposeChange(id) {
+ $('#hc' + id).hide();
+ $('#pc' + id).show();
+ var textarea = $('#pt' + id);
+ textarea.val('').removeAttr('disabled');
+ textarea.slideUp('fast');
+ }
+
+ function toggleCommentMarkupBox(id) {
+ $('#mb' + id).toggle();
+ }
+
+ /** Handle when the user clicks on a sort by link. */
+ function handleReSort(link) {
+ var classes = link.attr('class').split(/\s+/);
+ for (var i=0; i<classes.length; i++) {
+ if (classes[i] != 'sort-option') {
+ by = classes[i].substring(2);
+ }
+ }
+ setComparator();
+ // Save/update the sortBy cookie.
+ var expiration = new Date();
+ expiration.setDate(expiration.getDate() + 365);
+ document.cookie= 'sortBy=' + escape(by) +
+ ';expires=' + expiration.toUTCString();
+ $('ul.comment-ul').each(function(index, ul) {
+ var comments = getChildren($(ul), true);
+ comments = sortComments(comments);
+ appendComments(comments, $(ul).empty());
+ });
+ }
+
+ /**
+ * Function to process a vote when a user clicks an arrow.
+ */
+ function handleVote(link) {
+ if (!opts.voting) {
+ showError("You'll need to login to vote.");
+ return;
+ }
+
+ var id = link.attr('id');
+ if (!id) {
+ // Didn't click on one of the voting arrows.
+ return;
+ }
+ // If it is an unvote, the new vote value is 0,
+ // Otherwise it's 1 for an upvote, or -1 for a downvote.
+ var value = 0;
+ if (id.charAt(1) != 'u') {
+ value = id.charAt(0) == 'u' ? 1 : -1;
+ }
+ // The data to be sent to the server.
+ var d = {
+ comment_id: id.substring(2),
+ value: value
+ };
+
+ // Swap the vote and unvote links.
+ link.hide();
+ $('#' + id.charAt(0) + (id.charAt(1) == 'u' ? 'v' : 'u') + d.comment_id)
+ .show();
+
+ // The div the comment is displayed in.
+ var div = $('div#cd' + d.comment_id);
+ var data = div.data('comment');
+
+ // If this is not an unvote, and the other vote arrow has
+ // already been pressed, unpress it.
+ if ((d.value !== 0) && (data.vote === d.value * -1)) {
+ $('#' + (d.value == 1 ? 'd' : 'u') + 'u' + d.comment_id).hide();
+ $('#' + (d.value == 1 ? 'd' : 'u') + 'v' + d.comment_id).show();
+ }
+
+ // Update the comments rating in the local data.
+ data.rating += (data.vote === 0) ? d.value : (d.value - data.vote);
+ data.vote = d.value;
+ div.data('comment', data);
+
+ // Change the rating text.
+ div.find('.rating:first')
+ .text(data.rating + ' point' + (data.rating == 1 ? '' : 's'));
+
+ // Send the vote information to the server.
+ $.ajax({
+ type: "POST",
+ url: opts.processVoteURL,
+ data: d,
+ error: function(request, textStatus, error) {
+ showError('Oops, there was a problem casting that vote.');
+ }
+ });
+ }
+
+ /**
+ * Open a reply form used to reply to an existing comment.
+ */
+ function openReply(id) {
+ // Swap out the reply link for the hide link
+ $('#rl' + id).hide();
+ $('#cr' + id).show();
+
+ // Add the reply li to the children ul.
+ var div = $(renderTemplate(replyTemplate, {id: id})).hide();
+ $('#cl' + id)
+ .prepend(div)
+ // Setup the submit handler for the reply form.
+ .find('#rf' + id)
+ .submit(function(event) {
+ event.preventDefault();
+ addComment($('#rf' + id));
+ closeReply(id);
+ })
+ .find('input[type=button]')
+ .click(function() {
+ closeReply(id);
+ });
+ div.slideDown('fast', function() {
+ $('#rf' + id).find('textarea').focus();
+ });
+ }
+
+ /**
+ * Close the reply form opened with openReply.
+ */
+ function closeReply(id) {
+ // Remove the reply div from the DOM.
+ $('#rd' + id).slideUp('fast', function() {
+ $(this).remove();
+ });
+
+ // Swap out the hide link for the reply link
+ $('#cr' + id).hide();
+ $('#rl' + id).show();
+ }
+
+ /**
+ * Recursively sort a tree of comments using the comp comparator.
+ */
+ function sortComments(comments) {
+ comments.sort(comp);
+ $.each(comments, function() {
+ this.children = sortComments(this.children);
+ });
+ return comments;
+ }
+
+ /**
+ * Get the children comments from a ul. If recursive is true,
+ * recursively include childrens' children.
+ */
+ function getChildren(ul, recursive) {
+ var children = [];
+ ul.children().children("[id^='cd']")
+ .each(function() {
+ var comment = $(this).data('comment');
+ if (recursive)
+ comment.children = getChildren($(this).find('#cl' + comment.id), true);
+ children.push(comment);
+ });
+ return children;
+ }
+
+ /** Create a div to display a comment in. */
+ function createCommentDiv(comment) {
+ if (!comment.displayed && !opts.moderator) {
+ return $('<div class="moderate">Thank you! Your comment will show up '
+ + 'once it is has been approved by a moderator.</div>');
+ }
+ // Prettify the comment rating.
+ comment.pretty_rating = comment.rating + ' point' +
+ (comment.rating == 1 ? '' : 's');
+ // Make a class (for displaying not yet moderated comments differently)
+ comment.css_class = comment.displayed ? '' : ' moderate';
+ // Create a div for this comment.
+ var context = $.extend({}, opts, comment);
+ var div = $(renderTemplate(commentTemplate, context));
+
+ // If the user has voted on this comment, highlight the correct arrow.
+ if (comment.vote) {
+ var direction = (comment.vote == 1) ? 'u' : 'd';
+ div.find('#' + direction + 'v' + comment.id).hide();
+ div.find('#' + direction + 'u' + comment.id).show();
+ }
+
+ if (opts.moderator || comment.text != '[deleted]') {
+ div.find('a.reply').show();
+ if (comment.proposal_diff)
+ div.find('#sp' + comment.id).show();
+ if (opts.moderator && !comment.displayed)
+ div.find('#cm' + comment.id).show();
+ if (opts.moderator || (opts.username == comment.username))
+ div.find('#dc' + comment.id).show();
+ }
+ return div;
+ }
+
+ /**
+ * A simple template renderer. Placeholders such as <%id%> are replaced
+ * by context['id'] with items being escaped. Placeholders such as <#id#>
+ * are not escaped.
+ */
+ function renderTemplate(template, context) {
+ var esc = $(document.createElement('div'));
+
+ function handle(ph, escape) {
+ var cur = context;
+ $.each(ph.split('.'), function() {
+ cur = cur[this];
+ });
+ return escape ? esc.text(cur || "").html() : cur;
+ }
+
+ return template.replace(/<([%#])([\w\.]*)\1>/g, function() {
+ return handle(arguments[2], arguments[1] == '%' ? true : false);
+ });
+ }
+
+ /** Flash an error message briefly. */
+ function showError(message) {
+ $(document.createElement('div')).attr({'class': 'popup-error'})
+ .append($(document.createElement('div'))
+ .attr({'class': 'error-message'}).text(message))
+ .appendTo('body')
+ .fadeIn("slow")
+ .delay(2000)
+ .fadeOut("slow");
+ }
+
+ /** Add a link the user uses to open the comments popup. */
+ $.fn.comment = function() {
+ return this.each(function() {
+ var id = $(this).attr('id').substring(1);
+ var count = COMMENT_METADATA[id];
+ var title = count + ' comment' + (count == 1 ? '' : 's');
+ var image = count > 0 ? opts.commentBrightImage : opts.commentImage;
+ var addcls = count == 0 ? ' nocomment' : '';
+ $(this)
+ .append(
+ $(document.createElement('a')).attr({
+ href: '#',
+ 'class': 'sphinx-comment-open' + addcls,
+ id: 'ao' + id
+ })
+ .append($(document.createElement('img')).attr({
+ src: image,
+ alt: 'comment',
+ title: title
+ }))
+ .click(function(event) {
+ event.preventDefault();
+ show($(this).attr('id').substring(2));
+ })
+ )
+ .append(
+ $(document.createElement('a')).attr({
+ href: '#',
+ 'class': 'sphinx-comment-close hidden',
+ id: 'ah' + id
+ })
+ .append($(document.createElement('img')).attr({
+ src: opts.closeCommentImage,
+ alt: 'close',
+ title: 'close'
+ }))
+ .click(function(event) {
+ event.preventDefault();
+ hide($(this).attr('id').substring(2));
+ })
+ );
+ });
+ };
+
+ var opts = {
+ processVoteURL: '/_process_vote',
+ addCommentURL: '/_add_comment',
+ getCommentsURL: '/_get_comments',
+ acceptCommentURL: '/_accept_comment',
+ deleteCommentURL: '/_delete_comment',
+ commentImage: '/static/_static/comment.png',
+ closeCommentImage: '/static/_static/comment-close.png',
+ loadingImage: '/static/_static/ajax-loader.gif',
+ commentBrightImage: '/static/_static/comment-bright.png',
+ upArrow: '/static/_static/up.png',
+ downArrow: '/static/_static/down.png',
+ upArrowPressed: '/static/_static/up-pressed.png',
+ downArrowPressed: '/static/_static/down-pressed.png',
+ voting: false,
+ moderator: false
+ };
+
+ if (typeof COMMENT_OPTIONS != "undefined") {
+ opts = jQuery.extend(opts, COMMENT_OPTIONS);
+ }
+
+ var popupTemplate = '\
+ <div class="sphinx-comments" id="sc<%id%>">\
+ <p class="sort-options">\
+ Sort by:\
+ <a href="#" class="sort-option byrating">best rated</a>\
+ <a href="#" class="sort-option byascage">newest</a>\
+ <a href="#" class="sort-option byage">oldest</a>\
+ </p>\
+ <div class="comment-header">Comments</div>\
+ <div class="comment-loading" id="cn<%id%>">\
+ loading comments... <img src="<%loadingImage%>" alt="" /></div>\
+ <ul id="cl<%id%>" class="comment-ul"></ul>\
+ <div id="ca<%id%>">\
+ <p class="add-a-comment">Add a comment\
+ (<a href="#" class="comment-markup" id="ab<%id%>">markup</a>):</p>\
+ <div class="comment-markup-box" id="mb<%id%>">\
+ reStructured text markup: <i>*emph*</i>, <b>**strong**</b>, \
+ <tt>``code``</tt>, \
+ code blocks: <tt>::</tt> and an indented block after blank line</div>\
+ <form method="post" id="cf<%id%>" class="comment-form" action="">\
+ <textarea name="comment" cols="80"></textarea>\
+ <p class="propose-button">\
+ <a href="#" id="pc<%id%>" class="show-propose-change">\
+ Propose a change ▹\
+ </a>\
+ <a href="#" id="hc<%id%>" class="hide-propose-change">\
+ Propose a change ▿\
+ </a>\
+ </p>\
+ <textarea name="proposal" id="pt<%id%>" cols="80"\
+ spellcheck="false"></textarea>\
+ <input type="submit" value="Add comment" />\
+ <input type="hidden" name="node" value="<%id%>" />\
+ <input type="hidden" name="parent" value="" />\
+ </form>\
+ </div>\
+ </div>';
+
+ var commentTemplate = '\
+ <div id="cd<%id%>" class="sphinx-comment<%css_class%>">\
+ <div class="vote">\
+ <div class="arrow">\
+ <a href="#" id="uv<%id%>" class="vote" title="vote up">\
+ <img src="<%upArrow%>" />\
+ </a>\
+ <a href="#" id="uu<%id%>" class="un vote" title="vote up">\
+ <img src="<%upArrowPressed%>" />\
+ </a>\
+ </div>\
+ <div class="arrow">\
+ <a href="#" id="dv<%id%>" class="vote" title="vote down">\
+ <img src="<%downArrow%>" id="da<%id%>" />\
+ </a>\
+ <a href="#" id="du<%id%>" class="un vote" title="vote down">\
+ <img src="<%downArrowPressed%>" />\
+ </a>\
+ </div>\
+ </div>\
+ <div class="comment-content">\
+ <p class="tagline comment">\
+ <span class="user-id"><%username%></span>\
+ <span class="rating"><%pretty_rating%></span>\
+ <span class="delta"><%time.delta%></span>\
+ </p>\
+ <div class="comment-text comment"><#text#></div>\
+ <p class="comment-opts comment">\
+ <a href="#" class="reply hidden" id="rl<%id%>">reply ▹</a>\
+ <a href="#" class="close-reply" id="cr<%id%>">reply ▿</a>\
+ <a href="#" id="sp<%id%>" class="show-proposal">proposal ▹</a>\
+ <a href="#" id="hp<%id%>" class="hide-proposal">proposal ▿</a>\
+ <a href="#" id="dc<%id%>" class="delete-comment hidden">delete</a>\
+ <span id="cm<%id%>" class="moderation hidden">\
+ <a href="#" id="ac<%id%>" class="accept-comment">accept</a>\
+ </span>\
+ </p>\
+ <pre class="proposal" id="pr<%id%>">\
+<#proposal_diff#>\
+ </pre>\
+ <ul class="comment-children" id="cl<%id%>"></ul>\
+ </div>\
+ <div class="clearleft"></div>\
+ </div>\
+ </div>';
+
+ var replyTemplate = '\
+ <li>\
+ <div class="reply-div" id="rd<%id%>">\
+ <form id="rf<%id%>">\
+ <textarea name="comment" cols="80"></textarea>\
+ <input type="submit" value="Add reply" />\
+ <input type="button" value="Cancel" />\
+ <input type="hidden" name="parent" value="<%id%>" />\
+ <input type="hidden" name="node" value="" />\
+ </form>\
+ </div>\
+ </li>';
+
+ $(document).ready(function() {
+ init();
+ });
+})(jQuery);
+
+$(document).ready(function() {
+ // add comment anchors for all paragraphs that are commentable
+ $('.sphinx-has-comment').comment();
+
+ // highlight search words in search results
+ $("div.context").each(function() {
+ var params = $.getQueryParameters();
+ var terms = (params.q) ? params.q[0].split(/\s+/) : [];
+ var result = $(this);
+ $.each(terms, function() {
+ result.highlightText(this.toLowerCase(), 'highlighted');
+ });
+ });
+
+ // directly open comment window if requested
+ var anchor = document.location.hash;
+ if (anchor.substring(0, 9) == '#comment-') {
+ $('#ao' + anchor.substring(9)).click();
+ document.location.hash = '#s' + anchor.substring(9);
+ }
+});
More information about the llvm-commits
mailing list