replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

[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:
Jordan Rose 2013-04-17 00:57:39 +00:00
parent 4e225c0646
commit 406503a0f9
3 changed files with 37 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
clang/www/analyzer/dev_cxx.html
View File

@ -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>

1
clang/www/analyzer/menu.html.incl
View File

@ -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>

42
clang/www/analyzer/open_projects.html
View File

@ -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>