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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
