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

[George Karpenkov via Phabricator via cfe-commits]

george.karpenkov added inline comments.
Herald added a subscriber: dkrupp.


================
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.
----------------
NoQ wrote:
> 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."
Let's ignore (3) as a red herring, but I'm not sure I see the difference between (1), (2) and (4). When someone works actively on a checker, but then stops, it immediately transfers from state (4) to state (2) and optionally (1)


================
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>
----------------
NoQ wrote:
> I guess let's add the rest of the constructors from my message above.
What message above? The original email?


https://reviews.llvm.org/D53024