Imported Upstream version 6.10.0.49

Former-commit-id: 1d6753294b2993e1fbf92de9366bb9544db4189b

external/llvm-project/clang/www/OpenProjects.html

@@ -0,0 +1,132 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+          "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+  <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+  <title>Clang - Get Involved</title>
+  <link type="text/css" rel="stylesheet" href="menu.css">
+  <link type="text/css" rel="stylesheet" href="content.css">
+</head>
+<body>
+
+<!--#include virtual="menu.html.incl"-->
+
+<div id="content">
+
+<h1>Open Clang Projects</h1>
+
+<p>Here are a few tasks that are available for newcomers to work on, depending
+on what your interests are.  This list is provided to generate ideas, it is not
+intended to be comprehensive.  Please ask on cfe-dev for more specifics or to
+verify that one of these isn't already completed. :)</p>
+
+<ul>
+<li><b>Undefined behavior checking</b>:
+Improve and extend the runtime checks for undefined behavior which CodeGen
+inserts for the various <tt>-fsanitize=</tt> modes. A lot of issues can already
+be caught, but there is more to do here.</li>
+
+<li><b>Improve target support</b>: The current target interfaces are heavily
+stubbed out and need to be implemented fully.  See the FIXME's in TargetInfo.
+Additionally, the actual target implementations (instances of TargetInfoImpl)
+also need to be completed.</li>
+
+<li><b>Implement an tool to generate code documentation</b>: Clang's
+library-based design allows it to be used by a variety of tools that reason
+about source code. One great application of Clang would be to build an
+auto-documentation system like doxygen that generates code documentation from
+source code. The advantage of using Clang for such a tool is that the tool would
+use the same preprocessor/parser/ASTs as the compiler itself, giving it a very
+rich understanding of the code. Clang is already able to read and understand
+doxygen markup, but cannot yet generate documentation from it.</li>
+
+<li><b>Use clang libraries to implement better versions of existing tools</b>:
+Clang is built as a set of libraries, which means that it is possible to
+implement capabilities similar to other source language tools, improving them
+in various ways.  Three examples are <a
+href="http://distcc.samba.org/">distcc</a>, the <a
+href="http://delta.tigris.org/">delta testcase reduction tool</a>, and the
+"indent" source reformatting tool.
+distcc can be improved to scale better and be more efficient.  Delta could be
+faster and more efficient at reducing C-family programs if built on the clang
+preprocessor. The clang-based indent replacement,
+<a href="http://clang.llvm.org/docs/ClangFormat.html">clang-format</a>,
+could be taught to handle simple structural rules like those in <a
+href="http://llvm.org/docs/CodingStandards.html#hl_earlyexit">the LLVM coding
+standards</a>.</li>
+
+<li><b>Use clang libraries to extend Ragel with a JIT</b>: <a 
+href="http://research.cs.queensu.ca/~thurston/ragel/">Ragel</a> is a state
+machine compiler that lets you embed C code into state machines and generate
+C code.  It would be relatively easy to turn this into a JIT compiler using
+LLVM.</li>
+
+<li><b>Self-testing using clang</b>: There are several neat ways to
+improve the quality of clang by self-testing. Some examples:
+<ul>
+  <li>Improve the reliability of AST printing and serialization by
+  ensuring that the AST produced by clang on an input doesn't change
+  when it is reparsed or unserialized.
+
+  <li>Improve parser reliability and error generation by automatically
+  or randomly changing the input checking that clang doesn't crash and
+  that it doesn't generate excessive errors for small input
+  changes. Manipulating the input at both the text and token levels is
+  likely to produce interesting test cases.
+</ul>
+</li>
+
+<li><b>Continue work on C++1y support</b>:
+  C++98 and C++11 are feature-complete, but there are still several C++1y features to
+  implement.  Please see the <a href="cxx_status.html">C++ status report
+  page</a> to find out what is missing.</li>
+
+<li><b>StringRef'ize APIs</b>: A thankless but incredibly useful project is
+StringRef'izing (converting to use <tt>llvm::StringRef</tt> instead of <tt>const
+char *</tt> or <tt>std::string</tt>) various clang interfaces. This generally
+simplifies the code and makes it more efficient.</li>
+
+<li><b>Universal Driver</b>: Clang is inherently a cross compiler. We would like
+to define a new model for cross compilation which provides a great user
+experience -- it should be easy to cross compile applications, install support
+for new architectures, access different compilers and tools, and be consistent
+across different platforms. See the <a href="UniversalDriver.html">Universal
+Driver</a> web page for more information.</li>
+
+<li><b>XML Representation of ASTs</b>: Clang maintains a rich Abstract Syntax Tree that describes the program. Clang could emit an XML document that describes the program, which others tools could consume rather than being tied directly to the Clang binary.The XML representation needs to meet several requirements:
+  <ul>
+    <li><i>General</i>, so that it's able to represent C/C++/Objective-C abstractly, and isn't tied to the specific internal ASTs that Clang uses.</li>
+    <li><i>Documented</i>, with appropriate Schema against which the output of Clang's XML formatter can be verified.</li>
+    <li><i>Stable</i> across Clang versions.</li>
+  </ul></li>
+
+<li><b>Configuration Manager</b>: Clang/LLVM works on a large number of
+architectures and operating systems and can cross-compile to a similarly large
+number of configurations, but the pitfalls of chosing the command-line
+options, making sure the right sub-architecture is chosen and that the correct
+optional elements of your particular system can be a pain.
+
+<p>A tool that would investigate hosts and targets, and store the configuration
+in files that can later be used by Clang itself to avoid command-line options,
+especially the ones regarding which target options to use, would greatle alleviate
+this problem. A simple tool, with little or no dependency on LLVM itself, that
+will investigate a target architecture by probing hardware, software, libraries
+and compiling and executing code to identify all properties that would be relevant
+to command-line options (VFP, SSE, NEON, ARM vs. Thumb etc), triple settings etc.</p>
+
+<p>The first stage is to build a CFLAGS for Clang that would produce code on the
+current Host to the identified Target.</p>
+
+<p>The second stage would be to produce a configuration file (that can be used
+independently of the Host) so that Clang can read it and not need a gazillion
+of command-line options. Such file should be simple JSON / INI or anything that
+a text editor could change.</p>
+</ul>
+
+<p>If you hit a bug with clang, it is very useful for us if you reduce the code
+that demonstrates the problem down to something small.  There are many ways to
+do this; ask on cfe-dev for advice.</p>
+
+</div>
+</body>
+</html>

external/llvm-project/clang/www/UniversalDriver.html

@@ -0,0 +1,87 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+          "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+  <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+  <title>Clang - Universal Driver</title>
+  <link type="text/css" rel="stylesheet" href="menu.css">
+  <link type="text/css" rel="stylesheet" href="content.css">
+</head>
+<body>
+
+<!--#include virtual="menu.html.incl"-->
+
+<div id="content">
+
+<h1>The Clang Universal Driver Project</h1>
+
+<p>Clang is inherently a cross compiler, in that it is always capable of
+building code for targets which are a different architecture or even operating
+system from the one running the compiler. However, actually cross compiling in
+practice involves much more than just generating the right assembly code for a
+target, it also requires having an appropriate tool chain (assemblers, linkers),
+access to header files and libraries for the target, and many other details (for
+example, the calling convention or whether software floating point is in
+use). Traditionally, compilers and development environments provide little
+assistance with this process, so users do not have easy access to the powerful
+underlying cross-compilation abilities of clang.</p>
+
+<p>We would like to solve this problem by defining a new model for how cross
+compilation is done, based on the idea of a <i>universal driver</i>. The key
+point of this model is that the user would always access the compiler through a
+single entry point (e.g., <tt>/usr/bin/cc</tt>) and provide an argument
+specifying the <i>configuration</i> they would like to target. Under the hood
+this entry point (the universal driver) would have access to all the information
+that the driver, compiler, and other tools need to build applications for that
+target.</p>
+
+<p>This is a large and open-ended project. It's eventual success depends not
+just on implementing the model, but also on getting buy-in from compiler
+developers, operating system distribution vendors and the development community
+at large. Our plan is to begin by defining a clear list of the problems we want
+to solve and a proposed implementation (from the user perspective).</p>
+
+<p>This project is in the very early (i.e., thought experiment) stages of
+development. Stay tuned for more information, and of course, patches
+welcome!</p>
+
+<p>See also <a href="http://llvm.org/PR4127">PR4127</a>.</p>
+
+<h2>Existing Solutions and Related Work</h2>
+
+<ul>
+  <li>gcc's command line arguments <tt>-V</tt>, <tt>-B</tt>, <tt>-b</tt> are
+    generic but limited solutions to related problems. Similarly, <tt>-m32</tt>
+    and <tt>-m64</tt> solve a small subset of the problem for specific
+    architectures.</li>
+
+  <li>gcc's <a href="http://www.airs.com/ian/configure/configure_8.html">multilibs</a>
+    solve the part of the problem that relates to finding appropriate libraries
+    and include files based on particular feature support (soft float,
+    etc.).</li>
+
+  <li>Apple's "driver driver" supported by gcc and clang solve a subset of the
+    problem by supporting <tt>-arch</tt>. Apple also provides a tool chain which
+    supports <a href="http://en.wikipedia.org/wiki/Universal_binary">universal
+    binaries</a> and object files which may include data for multiple
+    architectures. See <a href="http://developer.apple.com/mac/library/technotes/tn2005/tn2137.html">TN2137</a>
+    for an example of how this is used.</li>
+
+  <li>Many operating systems and environments solve the problem by installing
+    complete development environments (including the IDE, tools, header files,
+    and libraries) for a single tool chain. This is cumbersome for users and
+    does not match well with tools which are inherently capable of cross
+    compiling.</li>
+
+  <li>The Debian <a href="http://wiki.debian.org/ArmEabiPort">ArmEabiPort</a>
+    wiki page for their work to support the ARM EABI provide an interesting
+    glimpse into how related issues impact the operating system distribution.</li>
+
+  <li><a href="http://icculus.org/fatelf/">FatELF</a> is a proposal for bringing
+    Mac OS X like "Universal Binary" support to ELF based platforms.</li>
+
+</ul>
+
+</div>
+</body>
+</html>

external/llvm-project/clang/www/analyzer/content.css

@@ -0,0 +1,100 @@
+html { margin: 0px; } body { margin: 8px; }
+
+html, body {
+  padding:0px;
+  margin:0px;
+  font-size:small; font-family:"Lucida Grande", "Lucida Sans Unicode", Arial, Verdana, Helvetica, sans-serif; background-color: #fff; color: #222;
+  line-height:1.5;
+  background-color: #808080;
+  
+}
+
+h1, h2, h3, tt { color: #000 }
+
+h1 { padding-top:0px; margin-top:0px;}
+h2 { color:#333333; padding-top:0.5em; }
+h3 { padding-top: 0.5em; margin-bottom: -0.25em; color:#2d58b7 }
+h4 { color:#2d58b7 }
+h4.faq { color:#2d58b7 }
+li { padding-bottom: 0.5em }
+ul { padding-left:1.5em; }
+
+.command { font-weight:bold }
+.code_highlight { font-weight:bold; color:#2d58b7 }
+.code_example { border-width:1px; border-style:solid; border-color:#cccccc; 
+                background-color:#eeeeee; padding:10px }
+
+/* Slides */
+IMG.img_slide {
+    display: block;
+    margin-left: auto;
+    margin-right: auto
+}
+
+#page { width:930px;  text-align: left; margin: 0 auto; padding:0;
+        background-color: white; height:100%;
+        border-left: 1px solid #EBF0FA;
+}
+
+#content {
+  clear: left;
+  padding: 1em 2em 1em 2em;
+  background-color: #ffffff;
+}
+
+.itemTitle { color:#2d58b7 }
+
+
+/* Tables */
+tr { vertical-align:top }
+
+table.options thead {
+  background-color:#eee; color:#666666;
+  font-weight: bold; cursor: default;
+  text-align:left;
+  border-top: 2px solid #cccccc;
+  border-bottom: 2px solid #cccccc;
+  font-weight: bold; font-family: Verdana
+}
+table.options { border: 1px #cccccc solid }
+table.options { border-collapse: collapse; border-spacing: 0px }
+table.options { margin-left:0px; margin-top:20px; margin-bottom:20px }
+table.options td { border-bottom: 1px #cccccc dotted }
+table.options td { padding:5px; padding-left:8px; padding-right:8px }
+table.options td { text-align:left; font-size:9pt }
+
+table.checkers { 
+  border: 1px #cccccc solid;
+  border-collapse: collapse;
+  margin:0px; margin-top:20px; margin-bottom:20px;
+  text-align:left;
+  table-layout: fixed;
+  width: 100%;
+  word-wrap :break-word;
+  font-size: 100%;
+}
+table.checkers thead {
+  background-color:#eee; color:#666666;
+  border-top: 2px solid #cccccc;
+  border-bottom: 2px solid #cccccc;
+  font-weight: bold; font-family: Verdana;
+}
+table.checkers td { border-right: 1px #cccccc dotted; border-bottom: 1px #cccccc dotted; }
+table.checkers td.aligned { text-align: center; vertical-align: middle; }
+table.checkers col.namedescr { width: 45% }
+table.checkers col.example { width: 55% }
+table.checkers col.progress { width: 84px }
+table.checkers thead td,
+table.checkers div.namedescr,
+table.checkers div.exampleContainer { overflow: hidden; padding: 5px 8px 10px 8px }
+/* table.checkers tbody div.example { font-family: monospace; white-space: pre } */
+table.checkers div.example { border-top:1px #cccccc dashed; width:100%; padding-top: 5px; margin-top: 5px }
+table.checkers div.example:first-child { border-top:none; padding-top: 0px; margin-top: 0px }
+table.checkers span.name { font-weight: bold }
+table.checkers span.lang { font-weight: bold; padding-left: 7px; /* display:block; */ }
+table.checkers div.descr { margin-top:7px }
+table.checkers div.functions { margin-top: 2px; font-style: italic; font-size: 90%; color:#00B }
+table.checkers pre { margin: 1px; font-size: 100%; word-wrap: break-word }
+table.checkers p { margin: 10px 0px 0px 0px; }
+table.checkers ul, li { margin: 0 }
+

external/llvm-project/clang/www/analyzer/faq.html

@@ -0,0 +1,227 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+          "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+  <title>FAQ and How to Deal with Common False Positives</title>
+  <link type="text/css" rel="stylesheet" href="menu.css">
+  <link type="text/css" rel="stylesheet" href="content.css">
+  <script type="text/javascript" src="scripts/menu.js"></script>
+  <style type="text/css">
+    tr:first-child { width:20%; }
+  </style>
+</head>
+<body>
+
+<div id="page">
+<!--#include virtual="menu.html.incl"-->
+
+<div id="content">
+
+<h1>FAQ and How to Deal with Common False Positives</h1>
+
+<ol>
+  <li><a href="#custom_assert">How do I tell the analyzer that I do not want the bug being
+reported here since my custom error handler will safely end the execution before
+the bug is reached?</a></li>
+  <li><a href="#null_pointer">The analyzer reports a null dereference, but I know that the
+pointer is never null. How can I tell the analyzer that a pointer can never be
+null?</a></li>
+  <li><a href="#dead_store">How do I tell the static analyzer that I don't care about a specific dead store?</a></li>
+  <li><a href="#unused_ivar">How do I tell the static analyzer that I don't care about a specific unused instance variable in Objective C?</a></li>
+  <li><a href="#unlocalized_string">How do I tell the static analyzer that I don't care about a specific unlocalized string?</a></li>
+  <li><a href="#dealloc_mrr">How do I tell the analyzer that my instance variable does not need to be released in -dealloc under Manual Retain/Release?</a></li>
+  <li><a href="#decide_nullability">How do I decide whether a method's return type should be _Nullable or _Nonnull?</a></li>
+  <li><a href="#nullability_intentional_violation">How do I tell the analyzer that I am intentionally violating nullability?</a></li>
+  <li><a href="#use_assert">The analyzer assumes that a loop body is never entered.  How can I tell it that the loop body will be entered at least once?</a></li>
+  <li><a href="#suppress_issue">How can I suppress a specific analyzer warning?</a></li>
+  <li><a href="#exclude_code">How can I selectively exclude code the analyzer examines?</a></li>
+</ol>
+
+
+<h4 id="custom_assert" class="faq">Q: How do I tell the analyzer that I do not want the bug being
+reported here since my custom error handler will safely end the execution before
+the bug is reached?</h4>
+
+<img src="images/example_custom_assert.png" alt="example custom assert">
+
+<p>You can tell the analyzer that this path is unreachable by teaching it about your <a href = "annotations.html#custom_assertions" >custom assertion handlers</a>. For example, you can modify the code segment as following.</p>
+
+<pre class="code_example">
+void customAssert() <span class="code_highlight">__attribute__((analyzer_noreturn))</span>;
+int foo(int *b) {
+  if (!b)
+    customAssert();
+  return *b;
+}</pre>
+
+
+<h4 id="null_pointer" class="faq">Q: The analyzer reports a null dereference, but I know that the
+pointer is never null. How can I tell the analyzer that a pointer can never be
+null?</h4>
+
+<img src="images/example_null_pointer.png" alt="example null pointer">
+
+<p>The reason the analyzer often thinks that a pointer can be null is because the preceding code checked compared it against null. So if you are absolutely sure that it cannot be null, remove the preceding check and, preferably, add an assertion as well. For example, in the code segment above, it will be sufficient to remove the <tt>if (!b)</tt> check. </p>
+
+<pre class="code_example">
+void usePointer(int *b);
+int foo(int *b) {
+  usePointer(b);
+  return *b;
+}</pre>
+
+<h4 id="dead_store" class="faq">Q: How do I tell the static analyzer that I don't care about a specific dead store?</h4>
+
+<p>When the analyzer sees that a value stored into a variable is never used, it's going to produce a message similar to this one:
+<pre class="code_example">Value stored to 'x' is never read</pre>
+You can use the <tt>(void)x;</tt> idiom to acknowledge that there is a dead store in your code but you do not want it to be reported in the future.</p>
+
+<h4 id="unused_ivar" class="faq">Q: How do I tell the static analyzer that I don't care about a specific unused instance variable in Objective C?</h4>
+
+<p>When the analyzer sees that a value stored into a variable is never used, it is going to produce a message similar to this one:
+<pre class="code_example">Instance variable 'commonName' in class 'HappyBird' is never used by the methods in its @implementation</pre>
+You can add <tt>__attribute__((unused))</tt> to the instance variable declaration to suppress the warning.</p>
+
+<h4 id="unlocalized_string" class="faq">Q: How do I tell the static analyzer that I don't care about a specific unlocalized string?</h4>
+
+<p>When the analyzer sees that an unlocalized string is passed to a method that will present that string to the user, it is going to produce a message similar to this one:
+<pre class="code_example">User-facing text should use localized string macro</pre>
+
+If your project deliberately uses unlocalized user-facing strings (for example, in a debugging UI that is never shown to users), you can suppress the analyzer warnings (and document your intent) with a function that just returns its input but is annotated to return a localized string:
+<pre class="code_example">
+__attribute__((annotate("returns_localized_nsstring")))
+static inline NSString *LocalizationNotNeeded(NSString *s) {
+  return s;
+}
+</pre>
+
+You can then call this function when creating your debugging UI:
+<pre class="code_example">
+[field setStringValue:LocalizationNotNeeded(@"Debug")];
+</pre>
+
+Some projects may also find it useful to use NSLocalizedString but add "DNL" or "Do Not Localize" to the string contents as a convention:
+<pre class="code_example">
+UILabel *testLabel = [[UILabel alloc] init];
+NSString *s = NSLocalizedString(@"Hello &lt;Do Not Localize&gt;", @"For debug purposes");
+[testLabel setText:s];
+</pre>
+</p>
+
+<h4 id="dealloc_mrr" class="faq">Q: How do I tell the analyzer that my instance variable does not need to be released in -dealloc under Manual Retain/Release?</h4>
+
+<p>If your class only uses an instance variable for part of its lifetime, it may
+maintain an invariant guaranteeing that the instance variable is always released
+before -dealloc. In this case, you can silence a warning about a missing release
+by either adding <tt>assert(_ivar == nil)</tt> or an explicit release
+<tt>[_ivar release]</tt> (which will be a no-op when the variable is nil) in
+-dealloc. </p>
+
+<h4 id="decide_nullability" class="faq">Q: How do I decide whether a method's return type should be _Nullable or _Nonnull?</h4>
+
+<p> Depending on the implementation of the method, this puts you in one of five situations:
+<ol>
+<li>You actually never return nil.</li>
+<li>You do return nil sometimes, and callers are supposed to handle that. This
+includes cases where your method is documented to return nil given certain
+inputs.</li>
+<li>You return nil based on some external condition (such as an out-of-memory
+error), but the client can't do anything about it either.</li>
+<li>You return nil only when the caller passes input documented to be invalid.
+That means it's the client's fault.</li>
+<li>You return nil in some totally undocumented case.</li>
+</ol>
+</p>
+
+<p>In (1) you should annotate the method as returning a <tt>_Nonnull</tt>
+object.</p>
+<p>In (2) the method should be marked <tt>_Nullable.</tt></p>
+<p>In (3) you should probably annotate the method <tt>_Nonnull</tt>. Why?
+Because no callers will actually check for nil, given that they can't do
+anything about the situation and don't know what went wrong. At this point
+things have gone so poorly that there's basically no way to recover.</p>
+<p>The least happy case is (4) because the resulting program will almost
+certainly either crash or just silently do the wrong thing.
+If this is a new method or you control the callers, you can use
+<tt>NSParameterAssert()</tt> (or the equivalent) to check the precondition and
+remove the nil return. But if you don't control the callers and they rely on
+this behavior, you should return mark the method <tt>_Nonnull</tt> and return
+nil <a href="#nullability_intentional_violation">cast to _Nonnull</a> anyway.
+(Note that (4) doesn't apply in cases where the caller can't know they passed
+bad parameters. For example,
+<tt>+[NSData dataWithContentsOfFile:options:error:]</tt> will fail if the file
+doesn't exist, but there's no way to check for that in advance. This means
+you're really in (2).)</p>
+<p>If you're in (5), document it, then figure out if you're now in (2), (3), or
+(4). :-)</p>
+
+<h4 id="nullability_intentional_violation" class="faq">Q: How do I tell the analyzer that I am intentionally violating nullability?</h4>
+
+<p>In some cases, it may make sense for methods to intentionally violate
+nullability. For example, your method may &mdash; for reasons of backward
+compatibility &mdash; chose to return nil and log an error message in a method
+with a non-null return type when the client violated a documented precondition
+rather than check the precondition with <tt>NSAssert()</tt>. In these cases, you
+can suppress the analyzer warning with a cast:
+<pre class="code_example">
+    return (id _Nonnull)nil;
+</pre>
+Note that this cast does not affect code generation.
+</p>
+
+<h4 id="use_assert" class="faq">Q: The analyzer assumes that a loop body is never entered.  How can I tell it that the loop body will be entered at least once?</h4>
+
+<img src="images/example_use_assert.png" alt="example use assert">
+
+<p> In the contrived example above, the analyzer has detected that the body of 
+the loop is never entered for the case where <tt>length <= 0</tt>. In this 
+particular example, you may know that the loop will always be entered because 
+the input parameter <tt>length</tt> will be greater than zero in all calls to this 
+function. You can teach the analyzer facts about your code as well as document 
+it by using assertions. By adding <tt>assert(length > 0)</tt> in the beginning 
+of the function, you tell the analyzer that your code is never expecting a zero 
+or a negative value, so it won't need to test the correctness of those paths.
+</p>
+
+<pre class="code_example">
+int foo(int length) {
+  int x = 0;
+  <span class="code_highlight">assert(length > 0);</span>
+  for (int i = 0; i < length; i++)
+    x += 1;
+  return length/x;
+}
+</pre>
+
+<h4 id="suppress_issue" class="faq">Q: How can I suppress a specific analyzer warning?</h4>
+
+<p>There is currently no solid mechanism for suppressing an analyzer warning,
+although this is currently being investigated. When you encounter an analyzer
+bug/false positive, check if it's one of the issues discussed above or if the
+analyzer <a href = "annotations.html#custom_assertions" >annotations</a> can 
+resolve the issue. Second, please <a href = "filing_bugs.html">report it</a> to 
+help us improve user experience. As the last resort, consider using <tt>__clang_analyzer__</tt> macro
+<a href = "faq.html#exclude_code" >described below</a>.</p>
+
+<h4 id="exclude_code" class="faq">Q: How can I selectively exclude code the analyzer examines?</h4>
+
+<p>When the static analyzer is using clang to parse source files, it implicitly 
+defines the preprocessor macro <tt>__clang_analyzer__</tt>. One can use this 
+macro to selectively exclude code the analyzer examines. Here is an example:
+
+<pre class="code_example">
+#ifndef __clang_analyzer__
+// Code not to be analyzed
+#endif
+</pre>
+
+This usage is discouraged because it makes the code dead to the analyzer from 
+now on. Instead, we prefer that users file bugs against the analyzer when it flags 
+false positives.
+</p>
+
+</div>
+</div>
+</body>
+</html>
+

external/llvm-project/clang/www/analyzer/filing_bugs.html

@@ -0,0 +1,62 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+          "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+  <title>Filing Bugs and Feature Requests</title>
+  <link type="text/css" rel="stylesheet" href="menu.css">
+  <link type="text/css" rel="stylesheet" href="content.css">
+  <script type="text/javascript" src="scripts/menu.js"></script>  
+</head>
+<body>
+
+<div id="page">
+<!--#include virtual="menu.html.incl"-->
+<div id="content">
+
+<h1>Filing Bugs and Feature Requests</h1>
+
+<p>We encourage users to file bug reports for any problems that they encounter.
+We also welcome feature requests. When filing a bug report, please do the
+following:</p>
+
+<ul>  
+
+<li>Include the checker build (for prebuilt Mac OS X binaries) or the SVN
+revision number.</li>
+
+<li>Provide a self-contained, reduced test case that exhibits the issue you are
+experiencing.</li>
+
+<li>Test cases don't tell us everything. Please briefly describe the problem you
+are seeing, including what you thought should have been the expected behavior
+and why.</li>
+
+</ul>
+
+<h2>Outside of Apple</h2>
+
+<h3>Bugzilla</h3>
+
+<p>Please <a href="http://llvm.org/bugs/enter_bug.cgi?product=clang">file
+bugs</a> in LLVM's Bugzilla database against the Clang <b>Static Analyzer</b>
+component.</p>
+
+<h3>Bugreporter.apple.com</h3>
+
+<p>If you are using the analyzer to analyze code associated with an Apple NDA
+(e.g., preview versions of SDKs or seed releases of Mac OS X) please file bug
+reports to Apple's <a href="http://bugreporter.apple.com">Bug Reporter</a> web
+site.</p>
+
+<p>You are free to always file bugs through this website, but this option is less
+attractive than filing bug reports through Bugzilla as not everyone who works on
+the analyzer has access to that bug database.</p>
+
+<h2>Apple-internal Users</h2>
+
+<p>Please file bugs in Radar against the <b>clang - static analyzer</b> component.</p>
+</div>
+</div>
+</body>
+</html>
+