[analyzer][docs][NFC] Fix some broken links and some cosmetic changes

[steakhal]

Summary

• We should report bugs to the GitHub Issues
• We should advocate using Discourse instead of the superseded cfe-dev mailing list.

There are a couple of other cosmetic changes such as preferring using
instead of typedef and quoting the -analyze-function parameter's
payload for escaping the braces.

Thanks @loic-joly-sonarsource for reporting this on Discord!

[Szelethus]

Cheers!

[NoQ]

Lovely!

Do you happen to know how stable are these doxygen hashes?

[steakhal]

In D119245#3305074, @NoQ wrote:

Lovely!

Do you happen to know how stable are these doxygen hashes?

IDK, but I think they should behave like the mangled names.

clang/www/analyzer/checker_dev_manual.html

 relies on a set of checkers to implement the logic for detecting and
 constructing specific bug reports. Anyone who is interested in implementing their own
 checker, should check out the Building a Checker in 24 Hours talk
 (<a href="https://llvm.org/devmtg/2012-11/Zaks-Rose-Checker24Hours.pdf">slides</a>
  <a href="https://youtu.be/kdxlsP5QVPw">video</a>)
 and refer to this page for additional information on writing a checker. The static analyzer is a
 part of the Clang project, so consult <a href="https://clang.llvm.org/hacking.html">Hacking on Clang</a>
 and <a href="https://llvm.org/docs/ProgrammersManual.html">LLVM Programmer's Manual</a>
-for developer guidelines and send your questions and proposals to
-<a href=https://lists.llvm.org/mailman/listinfo/cfe-dev>cfe-dev mailing list</a>.
+for developer guidelines and post your questions and proposals to the
+<a href="https://discourse.llvm.org/c/clang/static-analyzer/"> Static Analyzer</a> subcategory at
+the official <a href="https://discourse.llvm.org/"> LLVM Discourse server</a>.
 </p>
 
     <ul>
       <li><a href="#start">Getting Started</a></li>
       <li><a href="#analyzer">Static Analyzer Overview</a>
       <ul>
         <li><a href="#interaction">Interaction with Checkers</a></li>
         <li><a href="#values">Representing Values</a></li>
<ul>
     give you some ideas. </li>
 
     <li>How the current limitations of the analysis will effect the false alarm
     rate? Currently, the analyzer only reasons about one procedure at a time (no
     inter-procedural analysis). Also, it uses a simple range tracking based
     solver to model symbolic execution.</li>
 
     <li>Consult the <a
-    href="https://bugs.llvm.org/buglist.cgi?query_format=advanced&amp;bug_status=NEW&amp;bug_status=REOPENED&amp;version=trunk&amp;component=Static%20Analyzer&amp;product=clang">Bugzilla database</a>
+    href="https://github.com/llvm/llvm-project/labels/clang%3Astatic%20analyzer">GitHub Issues</a>
     to get some ideas for new checkers and consider starting with improving/fixing
     bugs in the existing checkers.</li>
   </ul>
 
 <p>Once an idea for a checker has been chosen, there are two key decisions that
 need to be made:
   <ul>
     <li> Which events the checker should be tracking. This is discussed in more

 
 <ul>
 <li><a
 href="https://clang.llvm.org/doxygen/ProgramStateTrait_8h.html#ae4cddb54383cd702a045d7c61b009147">REGISTER_TRAIT_WITH_PROGRAMSTATE</a>:
 Used when the state information is a single value. The methods available for
 state types declared with this macro are <tt>get</tt>, <tt>set</tt>, and
 <tt>remove</tt>.
 <li><a
-href="https://clang.llvm.org/doxygen/CheckerContext_8h.html#aa27656fa0ce65b0d9ba12eb3c02e8be9">REGISTER_LIST_WITH_PROGRAMSTATE</a>:
+href="https://clang.llvm.org/doxygen/ProgramStateTrait_8h.html#aa27656fa0ce65b0d9ba12eb3c02e8be9">REGISTER_LIST_WITH_PROGRAMSTATE</a>:
 Used when the state information is a list of values. The methods available for
 state types declared with this macro are <tt>add</tt>, <tt>get</tt>,
 <tt>remove</tt>, and <tt>contains</tt>.
 <li><a
-href="https://clang.llvm.org/doxygen/CheckerContext_8h.html#ad90f9387b94b344eaaf499afec05f4d1">REGISTER_SET_WITH_PROGRAMSTATE</a>:
+href="https://clang.llvm.org/doxygen/ProgramStateTrait_8h.html#ad90f9387b94b344eaaf499afec05f4d1">REGISTER_SET_WITH_PROGRAMSTATE</a>:
 Used when the state information is a set of values. The methods available for
 state types declared with this macro are <tt>add</tt>, <tt>get</tt>,
 <tt>remove</tt>, and <tt>contains</tt>.
 <li><a
-href="https://clang.llvm.org/doxygen/CheckerContext_8h.html#a6d1893bb8c18543337b6c363c1319fcf">REGISTER_MAP_WITH_PROGRAMSTATE</a>:
+href="https://clang.llvm.org/doxygen/ProgramStateTrait_8h.html#a6d1893bb8c18543337b6c363c1319fcf">REGISTER_MAP_WITH_PROGRAMSTATE</a>:
 Used when the state information is a map from a key to a value. The methods
 available for state types declared with this macro are <tt>add</tt>,
 <tt>set</tt>, <tt>get</tt>, <tt>remove</tt>, and <tt>contains</tt>.
 </ul>
 
 <p>All of these macros take as parameters the name to be used for the custom
 category of state information and the data type(s) to be used for storage. The
 data type(s) specified will become the parameter type and/or return type of the

 <a
 href="https://llvm.org/doxygen/classllvm_1_1ImmutableSet.html">llvm::ImmutableSet</a>,
 or <a
 href="https://llvm.org/doxygen/classllvm_1_1ImmutableMap.html">llvm::ImmutableMap</a>
 templated class. For the <tt>ExampleDataType</tt> example above, the type
 created would be equivalent to writing the declaration:
 
 <pre class="code_example">
-typedef llvm::ImmutableMap&lt;SymbolRef, int&gt; ExampleDataTypeTy;
+using ExampleDataTypeTy = llvm::ImmutableMap&lt;SymbolRef, int&gt;;
 </pre>
 
 <p>These macros will cover a majority of use cases; however, they still have a
 few limitations. They cannot be used inside namespaces (since they expand to
 contain top-level namespace references), and the data types that they define
 cannot be referenced from more than one file.
 
 <p>Note that <tt>ProgramStates</tt> are immutable; instead of modifying an existing

 analysis, as the program can continue to run after the leak. Dereferencing a
 null pointer, on the other hand, should stop analysis, as there is no way for
 the program to meaningfully continue after such an error.
 
 <p>If analysis can continue, then the most recent <tt>ExplodedNode</tt>
 generated by the checker can be passed to the <tt>BugReport</tt> constructor
 without additional modification. This <tt>ExplodedNode</tt> will be the one
 returned by the most recent call to <a
-href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#a264f48d97809707049689c37aa35af78">CheckerContext::addTransition</a>.
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#a9717efea3fbc71523984160ae7ae9d41">CheckerContext::addTransition</a>.
 If no transition has been performed during the current callback, the checker should call <a
-href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#a264f48d97809707049689c37aa35af78">CheckerContext::addTransition()</a>
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#a9717efea3fbc71523984160ae7ae9d41">CheckerContext::addTransition()</a>
 and use the returned node for bug reporting.
 
 <p>If analysis can not continue, then the current state should be transitioned
 into a so-called <i>sink node</i>, a node from which no further analysis will be
 performed. This is done by calling the <a
-href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#adeea33a5a2bed190210c4a2bb807a6f0">
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#a249245cdf2384738921f134c8d7d909a">
 CheckerContext::generateSink</a> function; this function is the same as the
 <tt>addTransition</tt> function, but marks the state as a sink node. Like
 <tt>addTransition</tt>, this returns an <tt>ExplodedNode</tt> with the updated
 state, which can then be passed to the <tt>BugReport</tt> constructor.
 
 <p>
 After a <tt>BugReport</tt> is created, it should be passed to the analyzer core
-by calling <a href = "https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#ae7738af2cbfd1d713edec33d3203dff5">CheckerContext::emitReport</a>.
+by calling <a href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#af50a9f46f6ea787a2a8e4ad7f86576e7">CheckerContext::emitReport</a>.
 
 <h2 id=ast>AST Visitors</h2>
   Some checks might not require path-sensitivity to be effective. Simple AST walk
   might be sufficient. If that is the case, consider implementing a Clang
   compiler warning. On the other hand, a check might not be acceptable as a compiler
   warning; for example, because of a relatively high false positive rate. In this
   situation, AST callbacks <tt><b>checkASTDecl</b></tt> and
   <tt><b>checkASTCodeBody</b></tt> are your best friends.
<pre class="code">
     ANALYZE (Syntax): test.c foo
     ANALYZE (Path,  Inline_Regular): test.c foo
 </pre>
 
 <b>Note: </b> a fully qualified function name has to be used when selecting
 C++ functions and methods, Objective-C methods and blocks, e.g.:
 
 <pre class="code">
-    $ <b>clang -cc1 -analyze -analyzer-checker=core test.cc -analyze-function=foo(int)</b>
+    $ <b>clang -cc1 -analyze -analyzer-checker=core test.cc -analyze-function='foo(int)'</b>
 </pre>
 
 The fully qualified name can be found from the
 <tt><b>-analyzer-display-progress</b></tt> output.
 
 <p>The bug reporter mechanism removes path diagnostics inside intermediate
 function calls that have returned by the time the bug was found and contain
 no interesting pieces. Usually it is up to the checkers to produce more

 </ul>
 
 <h2 id=additioninformation>Additional Sources of Information</h2>
 
 Here are some additional resources that are useful when working on the Clang
 Static Analyzer:
 
 <ul>
-<li><a href="http://lcs.ios.ac.cn/~xuzb/canalyze/memmodel.pdf">Xu, Zhongxing &
+<li><a href="https://lcs.ios.ac.cn/~xzx/memmodel.pdf">Xu, Zhongxing &
 Kremenek, Ted & Zhang, Jian. (2010). A Memory Model for Static Analysis of C
 Programs.</a></li>
 <li><a href="https://github.com/llvm/llvm-project/blob/main/clang/lib/StaticAnalyzer/README.txt">
 The Clang Static Analyzer README</a></li>
-<li><a href="https://github.com/llvm/llvm-project/blob/main/clang/docs/analyzer/RegionStore.txt">
+<li><a href="https://github.com/llvm/llvm-project/blob/main/clang/docs/analyzer/developer-docs/RegionStore.rst">
 Documentation for how the Store works</a></li>
-<li><a href="https://github.com/llvm/llvm-project/blob/main/clang/docs/analyzer/IPA.txt">
+<li><a href="https://github.com/llvm/llvm-project/blob/main/clang/docs/analyzer/developer-docs/IPA.rst">
 Documentation about inlining</a></li>
 <li> The "Building a Checker in 24 hours" presentation given at the <a
 href="https://llvm.org/devmtg/2012-11">November 2012 LLVM Developer's
 meeting</a>. Describes the construction of SimpleStreamChecker. <a
 href="https://llvm.org/devmtg/2012-11/Zaks-Rose-Checker24Hours.pdf">Slides</a>
 and <a
 href="https://youtu.be/kdxlsP5QVPw">video</a>
 are available.</li>
 <li>
 <a href="https://github.com/haoNoQ/clang-analyzer-guide/releases/download/v0.1/clang-analyzer-guide-v0.1.pdf">
 Artem Degrachev: Clang Static Analyzer: A Checker Developer's Guide
 </a> (reading the previous items first might be a good idea)</li>
 <li>The list of <a href="implicit_checks.html">Implicit Checkers</a></li>
 <li> <a href="https://clang.llvm.org/doxygen">Clang doxygen</a>. Contains
 up-to-date documentation about the APIs available in Clang. Relevant entries
 have been linked throughout this page. Also of use is the
 <a href="https://llvm.org/doxygen">LLVM doxygen</a>, when dealing with classes
 from LLVM.</li>
-<li> The <a href="https://lists.llvm.org/mailman/listinfo/cfe-dev">
-cfe-dev mailing list</a>. This is the primary mailing list used for
-discussion of Clang development (including static code analysis). The
-<a href="https://lists.llvm.org/pipermail/cfe-dev">archive</a> also contains
-a lot of information.</li>
+<li>
+  The <a href="https://discourse.llvm.org/c/clang/"> Clang Frontent Discourse site</a>.
+  This is the primary forum discussing ideas and posting questions about Clang development.
+  For posting Clang Static Analyzer specific questions, please visit the
+  <a href="https://discourse.llvm.org/c/clang/static-analyzer/"> Static Analyzer subcategory</a>
+  of the same site. In the past, Static Analyzer discussions took place at the
+  <a href="https://lists.llvm.org/pipermail/cfe-dev/"> cfe-dev</a> mailing list, which is now
+  archived and superseeded by the mentioned Discourse site.
+</li>
 </ul>
 
 </div>
 </div>
 </body>
 </html>