[analyzer] [www] Minor improvements to the text in open_projects

llvm-svn: 344664

clang/www/analyzer/open_projects.html

@@ -27,17 +27,14 @@ <h1>Open Projects</h1>
     <p>New checkers which were contributed to the analyzer,
     but have not passed a rigorous evaluation process,
     are committed as "alpha checkers" (from "alpha version"),
-    and are not enabled by default.
+    and are not enabled by default.</p>
 
-    Ideally, only the checkers which are actively being worked on should be in
+    <p>Ideally, only the checkers which are actively being worked on should be in
     "alpha",
     but over the years the development of many of those has stalled.
-    Such checkers need a cleanup:
-    checkers which have been there for a long time should either
-    be improved up to a point where they can be enabled by default,
-    or removed, if such an improvement is not possible.
-    Most notably, these checkers could be "graduated" out of alpha
-    if a consistent effort is applied:
+    Such checkers should either be improved
+    up to a point where they can be enabled by default,
+    or removed from the analyzer entirely.
 
     <ul>
       <li><code>alpha.security.ArrayBound</code> and
@@ -48,7 +45,7 @@ <h1>Open Projects</h1>
       <a href="https://en.wikipedia.org/wiki/Widening_(computer_science)">loop widening</a> support.
       Additionally, it might be more promising to perform index checking based on
       <a href="https://en.wikipedia.org/wiki/Taint_checking">tainted</a> index values.
-      <i>(Difficulty: Medium)</i></p>
+      <p><i>(Difficulty: Medium)</i></p></p>
       </li>
 
       <li><code>alpha.cplusplus.MisusedMovedObject</code>
@@ -58,7 +55,7 @@ <h1>Open Projects</h1>
         which have a well-defined semantics for use-after-move.
         This property does not hold for STL objects, but is often the case
         for custom containers.
-      <i>(Difficulty: Medium)</i></p>
+      <p><i>(Difficulty: Medium)</i></p></p>
       </li>
 
       <li><code>alpha.unix.StreamChecker</code>
@@ -79,7 +76,7 @@ <h1>Open Projects</h1>
     </ul>
   </li>
 
-  <li>Improved C++ support
+  <li>Improve C++ support
   <ul>
     <li>Handle aggregate construction.
       <p><a href="https://en.cppreference.com/w/cpp/language/aggregate_initialization">Aggregates</a>
@@ -99,7 +96,7 @@ <h1>Open Projects</h1>
       <code>CXXConstructExpr::CK_NonVirtualBase</code></a> branch of
       <code>ExprEngine::VisitCXXConstructExpr()</code>
       with proper support for the feature.
-      <i> (Difficulty: Medium) </i></p>
+      <p><i>(Difficulty: Medium) </i></p></p>
     </li>
 
     <li>Handle constructors within <code>new[]</code>
@@ -139,14 +136,14 @@ <h1>Open Projects</h1>
       large gains can be achieved by supporting only a few cases:
       e.g. calling <code>.length()</code> on an empty
       <code>std::string</code> always yields zero.
-    <i>(Difficulty: Medium)</i><p>
+    <p><i>(Difficulty: Medium)</i></p><p>
     </li>
 
     <li>Enhance CFG to model exception-handling.
       <p>Currently exceptions are treated as "black holes", and exception-handling
       control structures are poorly modeled in order to be conservative.
       This could be improved for both C++ and Objective-C exceptions.
-      <i>(Difficulty: Medium)</i></p>
+      <p><i>(Difficulty: Hard)</i></p></p>
     </li>
   </ul>
   </li>
@@ -159,7 +156,7 @@ <h1>Open Projects</h1>
       This problem was
       previously <a href="http://lists.llvm.org/pipermail/cfe-dev/2017-March/052864.html">discussed</a>
       on the mailing list, but no solution was implemented.
-      <i> (Difficulty: Medium) </i></p>
+      <p><i> (Difficulty: Medium) </i></p></p>
     </li>
 
     <li>Floating-point support.
@@ -169,7 +166,7 @@ <h1>Open Projects</h1>
       and auditing existing code to make sure it doesn't
       make incorrect assumptions (most notably, that <code>X == X</code>
       is always true, since it does not hold for <code>NaN</code>).
-      <i> (Difficulty: Medium)</i></p>
+      <p><i> (Difficulty: Medium)</i></p></p>
     </li>
 
     <li>Improved loop execution modeling.
@@ -183,7 +180,7 @@ <h1>Open Projects</h1>
       but the <a href="https://en.wikipedia.org/wiki/Widening_(computer_science)">widening</a>
       problem still remains open.
 
-      <i> (Difficulty: Hard)</i></p>
+      <p><i> (Difficulty: Hard)</i></p></p>
     </li>
 
     <li>Basic function summarization support
@@ -195,7 +192,7 @@ <h1>Open Projects</h1>
       enough to be a large improvement over conservative evaluation.
       Such summaries could be obtained either syntactically,
       or using a dataflow framework.
-      <i>(Difficulty: Hard)</i><p>
+      <p><i>(Difficulty: Hard)</i></p><p>
     </li>
 
     <li>Implement a dataflow flamework.
@@ -213,15 +210,15 @@ <h1>Open Projects</h1>
       a few dataflow analyses (most notably, liveness),
       but they implemented in an ad-hoc fashion.
       A proper framework would enable us writing many more useful checkers.
-      <i> (Difficulty: Hard) </i></p>
+      <p><i> (Difficulty: Hard) </i></p></p>
     </li>
 
     <li>Track type information through casts more precisely.
       <p>The <code>DynamicTypePropagation</code>
       checker is in charge of inferring a region's
       dynamic type based on what operations the code is performing.
       Casts are a rich source of type information that the analyzer currently ignores.
-      <i>(Difficulty: Medium)</i></p>
+      <p><i>(Difficulty: Medium)</i></p></p>
     </li>
 
   </ul>
@@ -232,7 +229,7 @@ <h1>Open Projects</h1>
        contributors are welcome to fix any of the outstanding
        <a href="https://bugs.llvm.org/buglist.cgi?component=Static%20Analyzer&list_id=147756&product=clang&resolution=---">bugs</a>
        in the Bugzilla.
-       <i>(Difficulty: Anything)</i></p>
+       <p><i>(Difficulty: Anything)</i></p></p>
   </li>
 
 </ul>