blob: 8ae779fc8679f2a187a6174a54c254f5a43bfb52 [file] [log] [blame]
Anna Zaksa8d8a472013-04-16 21:37:04 +00001<!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 and
19power. Most of the projects listed here are infrastructure-related so this list
20is an addition to the <A href="potential_checkers.html">potential checkers list</A>.
21 If you are interested in tackling one of these, please send an email to
22<a href=http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>cfe-dev mailing list</a>
23to notify other members of the community.</p>
24<p>
25<ul>
26 <li>Core Analyzer Infrastructure
27 <ul>
28 <li>Explicitly model C++ standard library functions with <tt>BodyFarm</tt>.
29 <p><tt><a href="http://clang.llvm.org/doxygen/classclang_1_1BodyFarm.html">BodyFarm</a></tt>
30 allows the analyzer to explicitly model functions, whose definitions are
31 not available during analysis. Modeling more of the widely used functions
32 (such as <tt>std::string</tt>) will improve precision of the analysis.
33 <i>(Difficulty: Easy)</i><p>
34 </li>
35
36 <li>Implement generalized loop execution modeling.
37 <p>Currently, the analyzer simply unrolls each loop <tt>N</tt> times. This
38 means that it will not execute any code after the loop if the loop is
39 guaranteed to execute more than <tt>N</tt> times. This results in lost
40 basic block coverage. We could continue exploring the path if we could
41 model a generic <tt>i</tt>-th iteration of a loop.
42 <i> (Difficulty: Hard)</i></p>
43 </li>
44
45 <li>Enhance CFG to model C++ destructors and/or exceptions.
46 <p><i>(Difficulty: Medium)</i></p>
47
48 <li>Design and Implement alpha-renaming.
49 <p>Implement unifying two symbolic values along a path after they are
50 determined to be equal via comparison. This would allow us to reduce the
51 number of false positives and would be a building step to more advanced
52 analyzes, such as summary-based interprocedural and cross-translation-unit
53 analysis.
54 <i>(Difficulty: Hard)</i></p>
55 </li>
56 </ul>
57 </li>
58
59 <li>Bug Reporting
60 <ul>
61 <li>Add support for displaying multi-file path in scan-build output.
62 <p>Currently scan-build output does not display reports that span multiple
63 files. The main problem is that we do not have the infrastructure to
64 display such paths in HTML output. <i>(Difficulty: Medium)</i> </p>
65 </li>
66
67 <li>Relate bugs to checkers.
68 <p>We need to come up with bug reports API, which will relate bug reports
69 to the checkers that produce them and refactor the existing code to use the
70 new API. This would allow us to identify the checker from the bug report.
71 <i>(Difficulty: Medium-easy)</i></p>
72 </li>
73
74 <li>Refactor <a href="http://clang.llvm.org/doxygen/BugReporter_8cpp_source.html">BugReporter.cpp</a>.
75 <p>It would be great to have more code reuse between "Minimal" and
76 "Extensive" PathDiagnostic generation algorithms. One idea is to create an
77 IR for representing path diagnostics, which would be later be used to
78 generate minimal or extensive report output. <i>(Difficulty: Medium)</i></p>
79 </li>
80 </ul>
81 </li>
82
83 <li>Other Infrastructure
84 <ul>
85 <li>Create 'analyzer_annotate' attribute for the analyzer annotations.<p>
86 We would like to put all analyzer attributes behind a fence so that we
87 could add/remove them without worrying that compiler (not analyzer) users
88 depend on them. Design and implement such a generic analyzer attribute in
89 the compiler. <i>(Difficulty: Medium)</i></p>
90 </li>
91
92 <li>Rewrite scan-build (in python). <p><i>(Difficulty: Easy)</i></p>
93 </li>
94 </ul>
95 </li>
96
97 <li>Enhanced Checks
98 <ul>
99 <li>Implement a production-ready StreamChecker.
100 <p>A SimpleStreamChecker has been presented in the Building a Checker in 24
101 Hours talk
102 (<a href="http://llvm.org/devmtg/2012-11/Zaks-Rose-Checker24Hours.pdf">slides</a>
103 <a href="http://llvm.org/devmtg/2012-11/videos/Zaks-Rose-Checker24Hours.mp4">video</a>).
104 We need to implement a production version of the checker with richer set of
105 APIs and evaluate it by running on real codebases.
106 <i>(Difficulty: Easy)</i></p>
107 </li>
108
109 <li>Extend Malloc checker with reasoning about custom allocator,
110 deallocator, and ownership-transfer functions.
111 <p>This would require extending MallocPessimistic checker with reasoning
112 about annotated functions. It is strongly desired that one would rely on
113 the 'analyzer_annotate' attribute, as described in one of the items above.
114 <i>(Difficulty: Easy)</i></p>
115 </li>
116
117 <li>Implement iterators invalidation checker.
118 <p><i>(Difficulty: Easy)</i></p>
119 </li>
120
121 <li>Write checkers which catch Copy and Paste errors.
122 <p>Take a look at the following paper for inspiration
123 <a href="http://pages.cs.wisc.edu/~shanlu/paper/TSE-CPMiner.pdf">CP-Miner</a>.
124 <i>(Difficulty: Medium-hard)</i></p>
125 </li>
126 </ul>
127 </li>
128</ul>
129
130</div>
131</div>
132</body>
133</html>
134