[PATCH] D53024: [analyzer][www] Add more open projects

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.


================
Comment at: clang/www/analyzer/open_projects.html:27-32
+    <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.
+
+    The development of many such checkers has stalled over the years.
----------------
This is extremely important to get right. Alpha doesn't mean "i did an experiment, let me dump my code so that it wasn't lost, maybe others will pick it up and turn it into a useful checker if they figure out how". Alpha doesn't mean "a checker that power-users can use at their own risk when they want to find more bugs". Alpha doesn't mean "i think this checker is great but maintainers think it's bad so they keep me in alpha but i'm happy because i can write in my resume that i'm an llvm contributor". All of these are super popular misconceptions.

Alpha means "i'm working on it". That's it.

Let's re-phrase to something like: "When a new checker is being developed incrementally, it is committed into clang and is put into the hidden "alpha" package (from "alpha version"). Ideally, once all desired functionality of the checker is implemented, checker should be moved out of the alpha package and become enabled by default or recommended to opt-in into, but development of many alpha checkers has stalled over the years."


================
Comment at: clang/www/analyzer/open_projects.html:80
 
-    <li>Handle floating-point values.
-    <p>Currently, the analyzer treats all floating-point values as unknown.
-    However, we already have most of the infrastructure we need to handle
-    floats: RangeConstraintManager. This would involve adding a new SVal kind
-    for constant floats, generalizing the constraint manager to handle floats
-    and integers equally, and auditing existing code to make sure it doesn't
-    make untoward assumptions.
-    <i> (Difficulty: Medium)</i></p>
-    </li>
-    
-    <li>Implement generalized loop execution modeling.
-    <p>Currently, the analyzer simply unrolls each loop <tt>N</tt> times. This 
-    means that it will not execute any code after the loop if the loop is 
-    guaranteed to execute more than <tt>N</tt> times. This results in lost 
-    basic block coverage. We could continue exploring the path if we could 
-    model a generic <tt>i</tt>-th iteration of a loop.
-    <i> (Difficulty: Hard)</i></p>
+  <li>Improved C++ support
+  <ul>
----------------
I guess let's add the rest of the constructors from my message above.


================
Comment at: clang/www/analyzer/open_projects.html:88-89
+      but potentially calling
+      constructors for their fields and base classes
+      These
+      constructors of sub-objects need to know what object they are constructing.
----------------
Something's wrong here.


https://reviews.llvm.org/D53024