[analyzer] Merge C++ status page into Open Projects.
Also, add a few random extra open projects. Most of C++ support is done; we don't need the status page anymore. We're hoping that the C++-related open projects are the only major pieces of functionality we don't model at this point. llvm-svn: 179659
This commit is contained in:
parent
4e225c0646
commit
406503a0f9
|
@ -1,57 +0,0 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|
||||
"http://www.w3.org/TR/html4/strict.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<title>Analyzer Development: C++ Support</title>
|
||||
<link type="text/css" rel="stylesheet" href="menu.css">
|
||||
<link type="text/css" rel="stylesheet" href="content.css">
|
||||
<script type="text/javascript" src="scripts/menu.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<div id="page">
|
||||
<!--#include virtual="menu.html.incl"-->
|
||||
<div id="content">
|
||||
|
||||
<h1>C++ Support</h1>
|
||||
|
||||
<p>The Clang compiler <a
|
||||
href="http://clang.llvm.org/cxx_status.html">supports almost all of C++11</a>.
|
||||
Support in the frontend for C++ language features, however, does not
|
||||
automatically translate into support for those features in the static analyzer.
|
||||
Language features need to be specifically modeled in the static analyzer so
|
||||
their semantics can be properly analyzed. Support for analyzing C++ and
|
||||
Objective-C++ files is currently fairly basic.</p>
|
||||
|
||||
<p>Listed here are a set of open tasks that are prerequisites for
|
||||
decent analysis of C++. This list is also not complete; new tasks
|
||||
will be added as deemed necessary.</p>
|
||||
|
||||
<ul>
|
||||
<li>Control-Flow Graph Enhancements:
|
||||
<ul>
|
||||
<li>Model destructors for temporary objects</li>
|
||||
<li>Model the implicit allocator call to <tt>operator new</tt></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Path-Sensitive Analysis Engine (ExprEngine):
|
||||
<ul>
|
||||
<li>Allow constructors to be inlined</li>
|
||||
<li>Allow destructors to be inlined</li>
|
||||
<li>Fully model <tt>new</tt> and <tt>delete</tt></li>
|
||||
<li>Track type info through casts more precisely</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Checkers:
|
||||
<ul>
|
||||
<li>Check that <tt>new</tt> and <tt>delete</tt> are correctly paired</li>
|
||||
<li>For more ideas, see the <a href="potential_checkers.html">list of potential checkers</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -29,7 +29,6 @@
|
|||
<li><a href="/checker_dev_manual.html">Checker Developer Manual</a></li>
|
||||
<li><a href="/open_projects.html">Open Projects</a></li>
|
||||
<li><a href="/potential_checkers.html">Potential Future Checkers</a></li>
|
||||
<li><a href="/dev_cxx.html">Analysis Support for C++</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
|
|
|
@ -53,7 +53,30 @@ mailing list</a> to notify other members of the community.</p>
|
|||
control structures are poorly modeled (to be conservative). This could be
|
||||
much improved for both C++ and Objective-C exceptions.
|
||||
<i>(Difficulty: Medium)</i></p>
|
||||
|
||||
|
||||
<li>Enhance CFG to model C++ <code>new</code> more precisely.
|
||||
<p>The current representation of <code>new</code> does not provide an easy
|
||||
way for the analyzer to model the call to a memory allocation function
|
||||
(<code>operator new</code>), then initialize the result with a constructor
|
||||
call. The problem is discussed at length in
|
||||
<a href="http://llvm.org/bugs/show_bug.cgi?id=12014">PR12014</a>.
|
||||
<i>(Difficulty: Easy)</i></p>
|
||||
|
||||
<li>Enhance CFG to model C++ <code>delete</code> more precisely.
|
||||
<p>Similarly, the representation of <code>delete</code> does not include
|
||||
the call to the destructor, followed by the call to the deallocation
|
||||
function (<code>operator delete</code>). One particular issue
|
||||
(<tt>noreturn</tt> destructors) is discussed in
|
||||
<a href="http://llvm.org/bugs/show_bug.cgi?id=15599">PR15599</a>
|
||||
<i>(Difficulty: Easy)</i></p>
|
||||
|
||||
<li>Track type info through casts more precisely.
|
||||
<p>The DynamicTypePropagation checker is in charge of inferring a region's
|
||||
dynamic type based on what operations the code is performing. Casts are a
|
||||
rich source of type information that the analyzer currently ignores. They
|
||||
are tricky to get right, but might have very useful consequences.
|
||||
<i>(Difficulty: Medium)</i></p>
|
||||
|
||||
<li>Design and implement alpha-renaming.
|
||||
<p>Implement unifying two symbolic values along a path after they are
|
||||
determined to be equal via comparison. This would allow us to reduce the
|
||||
|
@ -93,6 +116,19 @@ mailing list</a> to notify other members of the community.</p>
|
|||
|
||||
<li>Other Infrastructure
|
||||
<ul>
|
||||
<li>Rewrite <tt>scan-build</tt> (in Python).
|
||||
<p><i>(Difficulty: Easy)</i></p>
|
||||
</li>
|
||||
|
||||
<li>Do a better job interposing on a compilation.
|
||||
<p>Currently, <tt>scan-build</tt> just sets the <tt>CC</tt> and <tt>CXX</tt>
|
||||
environment variables to its wrapper scripts, which then call into an
|
||||
underlying platform compiler. This is problematic for any project that
|
||||
doesn't exclusively use <tt>CC</tt> and <tt>CXX</tt> to control its
|
||||
compilers.
|
||||
<p><i>(Difficulty: Medium-Hard)</i></p>
|
||||
</li>
|
||||
|
||||
<li>Create an <tt>analyzer_annotate</tt> attribute for the analyzer
|
||||
annotations.
|
||||
<p>We would like to put all analyzer attributes behind a fence so that we
|
||||
|
@ -100,10 +136,6 @@ mailing list</a> to notify other members of the community.</p>
|
|||
depend on them. Design and implement such a generic analyzer attribute in
|
||||
the compiler. <i>(Difficulty: Medium)</i></p>
|
||||
</li>
|
||||
|
||||
<li>Rewrite <tt>scan-build</tt> (in Python).
|
||||
<p><i>(Difficulty: Easy)</i></p>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
|
|
Loading…
Reference in New Issue