| Anna Zaks | a8d8a47 | 2013-04-16 21:37:04 +0000 | [diff] [blame^] | 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 and | 
|  | 19 | power. Most of the projects listed here are infrastructure-related so this list | 
|  | 20 | is 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> | 
|  | 23 | to 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 |  |