239 lines · html
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"2 "http://www.w3.org/TR/html4/strict.dtd">3<html>4<head>5 <title>Open Projects</title>6 <link type="text/css" rel="stylesheet" href="menu.css">7 <link type="text/css" rel="stylesheet" href="content.css">8 <script type="text/javascript" src="scripts/menu.js"></script>9</head>10<body>11 12<div id="page">13<!--#include virtual="menu.html.incl"-->14<div id="content">15 16<h1>Open Projects</h1>17 18<p>This page lists several projects that would boost analyzer's usability and19power. Most of the projects listed here are infrastructure-related so this list20is an addition to the <a href="potential_checkers.html">potential checkers21list</a>. If you are interested in tackling one of these, please send an email22to the <a href=https://lists.llvm.org/mailman/listinfo/cfe-dev>cfe-dev23mailing list</a> to notify other members of the community.</p>24 25<ul>26 <li>Release checkers from "alpha"27 <p>New checkers which were contributed to the analyzer,28 but have not passed a rigorous evaluation process,29 are committed as "alpha checkers" (from "alpha version"),30 and are not enabled by default.</p>31 32 <p>Ideally, only the checkers which are actively being worked on should be in33 "alpha",34 but over the years the development of many of those has stalled.35 Such checkers should either be improved36 up to a point where they can be enabled by default,37 or removed from the analyzer entirely.38 </li>39 40 <li>Improve C++ support41 <ul>42 <li>Handle construction as part of aggregate initialization.43 <p><a href="https://en.cppreference.com/w/cpp/language/aggregate_initialization">Aggregates</a>44 are objects that can be brace-initialized without calling a45 constructor (that is, <code><a href="https://clang.llvm.org/doxygen/classclang_1_1CXXConstructExpr.html">46 CXXConstructExpr</a></code> does not occur in the AST),47 but potentially calling48 constructors for their fields and base classes49 These50 constructors of sub-objects need to know what object they are constructing.51 Moreover, if the aggregate contains52 references, lifetime extension needs to be properly modeled.53 54 One can start untangling this problem by trying to replace the55 current ad-hoc <code><a href="https://clang.llvm.org/doxygen/classclang_1_1ParentMap.html">56 ParentMap</a></code> lookup in <a href="https://clang.llvm.org/doxygen/ExprEngineCXX_8cpp_source.html#l00430">57 <code>CXXConstructionKind::NonVirtualBase</code></a> branch of58 <code>ExprEngine::VisitCXXConstructExpr()</code>59 with proper support for the feature.60 <p><i>(Difficulty: Medium) </i></p></p>61 </li>62 63 <li>Handle array constructors.64 <p>When an array of objects is allocated (say, using the65 <code>operator new[]</code> or defining a stack array),66 constructors for all elements of the array are called.67 We should model (potentially some of) such evaluations,68 and the same applies for destructors called from69 <code>operator delete[]</code>.70 See tests cases in <a href="https://github.com/llvm/llvm-project/tree/main/clang/test/Analysis/handle_constructors_with_new_array.cpp">handle_constructors_with_new_array.cpp</a>.71 </p>72 <p>73 Constructing an array requires invoking multiple (potentially unknown)74 amount of constructors with the same construct-expression.75 Apart from the technical difficulties of juggling program points around76 correctly to avoid accidentally merging paths together, we'll have to77 be a judge on when to exit the loop and how to widen it.78 Given that the constructor is going to be a default constructor,79 a nice 95% solution might be to execute exactly one constructor and80 then default-bind the resulting LazyCompoundVal to the whole array;81 it'll work whenever the default constructor doesn't touch global state82 but only initializes the object to various default values.83 But if, say, we're making an array of strings,84 depending on the implementation you might have to allocate a new buffer85 for each string, and in this case default-binding won't cut it.86 We might want to come up with an auxiliary analysis in order to perform87 widening of these simple loops more precisely.88 </p>89 </li>90 91 <li>Handle constructors that can be elided due to Named Return Value Optimization (NRVO)92 <p>Local variables which are returned by values on all return statements93 may be stored directly at the address for the return value,94 eliding the copy or move constructor call.95 Such variables can be identified using the AST call <code>VarDecl::isNRVOVariable</code>.96 </p>97 </li>98 99 <li>Handle constructors of lambda captures100 <p>Variables which are captured by value into a lambda require a call to101 a copy constructor.102 This call is not currently modeled.103 </p>104 </li>105 106 <li>Handle constructors for default arguments107 <p>Default arguments in C++ are recomputed at every call,108 and are therefore local, and not static, variables.109 See tests cases in <a href="https://github.com/llvm/llvm-project/tree/main/clang/test/Analysis/handle_constructors_for_default_arguments.cpp">handle_constructors_for_default_arguments.cpp</a>.110 </p>111 <p>112 Default arguments are annoying because the initializer expression is113 evaluated at the call site but doesn't syntactically belong to the114 caller's AST; instead it belongs to the ParmVarDecl for the default115 parameter. This can lead to situations when the same expression has to116 carry different values simultaneously -117 when multiple instances of the same function are evaluated as part of the118 same full-expression without specifying the default arguments.119 Even simply calling the function twice (not necessarily within the120 same full-expression) may lead to program points agglutinating because121 it's the same expression. There are some nasty test cases already122 in temporaries.cpp (struct DefaultParam and so on). I recommend adding a123 new LocationContext kind specifically to deal with this problem. It'll124 also help you figure out the construction context when you evaluate the125 construct-expression (though you might still need to do some additional126 CFG work to get construction contexts right).127 </p>128 </li>129 130 <li>Enhance the modeling of the standard library.131 <p>The analyzer needs a better understanding of STL in order to be more132 useful on C++ codebases.133 While full library modeling is not an easy task,134 large gains can be achieved by supporting only a few cases:135 e.g. calling <code>.length()</code> on an empty136 <code>std::string</code> always yields zero.137 <p><i>(Difficulty: Medium)</i></p><p>138 </li>139 140 <li>Enhance CFG to model exception-handling.141 <p>Currently exceptions are treated as "black holes", and exception-handling142 control structures are poorly modeled in order to be conservative.143 This could be improved for both C++ and Objective-C exceptions.144 <p><i>(Difficulty: Hard)</i></p></p>145 </li>146 </ul>147 </li>148 149 <li>Core Analyzer Infrastructure150 <ul>151 <li>Handle unions.152 <p>Currently in the analyzer the value of a union is always regarded as153 an unknown.154 This problem was155 previously <a href="https://lists.llvm.org/pipermail/cfe-dev/2017-March/052864.html">discussed</a>156 on the mailing list, but no solution was implemented.157 <p><i> (Difficulty: Medium) </i></p></p>158 </li>159 160 <li>Floating-point support.161 <p>Currently, the analyzer treats all floating-point values as unknown.162 This project would involve adding a new <code>SVal</code> kind163 for constant floats, generalizing the constraint manager to handle floats,164 and auditing existing code to make sure it doesn't165 make incorrect assumptions (most notably, that <code>X == X</code>166 is always true, since it does not hold for <code>NaN</code>).167 <p><i> (Difficulty: Medium)</i></p></p>168 </li>169 170 <li>Improved loop execution modeling.171 <p>The analyzer simply unrolls each loop <tt>N</tt> times before172 dropping the path, for a fixed constant <tt>N</tt>.173 However, that results in lost coverage in cases where the loop always174 executes more than <tt>N</tt> times.175 A Google Summer Of Code176 <a href="https://summerofcode.withgoogle.com/archive/2017/projects/6071606019358720/">project</a>177 was completed to make the loop bound parameterizable,178 but the <a href="https://en.wikipedia.org/wiki/Widening_(computer_science)">widening</a>179 problem still remains open.180 181 <p><i> (Difficulty: Hard)</i></p></p>182 </li>183 184 <li>Basic function summarization support185 <p>The analyzer performs inter-procedural analysis using186 either inlining or "conservative evaluation" (invalidating all data187 passed to the function).188 Often, a very simple summary189 (e.g. "this function is <a href="https://en.wikipedia.org/wiki/Pure_function">pure</a>") would be190 enough to be a large improvement over conservative evaluation.191 Such summaries could be obtained either syntactically,192 or using a dataflow framework.193 <p><i>(Difficulty: Hard)</i></p><p>194 </li>195 196 <li>Implement a dataflow flamework.197 <p>The analyzer core198 implements a <a href="https://en.wikipedia.org/wiki/Symbolic_execution">symbolic execution</a>199 engine, which performs checks200 (use-after-free, uninitialized value read, etc.)201 over a <em>single</em> program path.202 However, many useful properties203 (dead code, check-after-use, etc.) require204 reasoning over <em>all</em> possible in a program.205 Such reasoning requires a206 <a href="https://en.wikipedia.org/wiki/Data-flow_analysis">dataflow analysis</a> framework.207 Clang already implements208 a few dataflow analyses (most notably, liveness),209 but they implemented in an ad-hoc fashion.210 A proper framework would enable us writing many more useful checkers.211 <p><i> (Difficulty: Hard) </i></p></p>212 </li>213 214 <li>Track type information through casts more precisely.215 <p>The <code>DynamicTypePropagation</code>216 checker is in charge of inferring a region's217 dynamic type based on what operations the code is performing.218 Casts are a rich source of type information that the analyzer currently ignores.219 <p><i>(Difficulty: Medium)</i></p></p>220 </li>221 222 </ul>223 </li>224 225 <li>Fixing miscellaneous bugs226 <p>Apart from the open projects listed above,227 contributors are welcome to fix any of the outstanding228 <a href="https://bugs.llvm.org/buglist.cgi?component=Static%20Analyzer&list_id=147756&product=clang&resolution=---">bugs</a>229 in the Bugzilla.230 <p><i>(Difficulty: Anything)</i></p></p>231 </li>232 233</ul>234 235</div>236</div>237</body>238</html>239