[cfe-commits] r73190 - /cfe/trunk/www/OpenProjects.html

[Douglas Gregor]

Author: dgregor
Date: Thu Jun 11 09:53:37 2009
New Revision: 73190

URL: http://llvm.org/viewvc/llvm-project?rev=73190&view=rev
Log:
Prune some projects that have already been started

Modified:
    cfe/trunk/www/OpenProjects.html

Modified: cfe/trunk/www/OpenProjects.html
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/OpenProjects.html?rev=73190&r1=73189&r2=73190&view=diff

==============================================================================
--- cfe/trunk/www/OpenProjects.html (original)
+++ cfe/trunk/www/OpenProjects.html Thu Jun 11 09:53:37 2009
@@ -26,13 +26,7 @@
 rejected or miscompiled by the front-end. If you notice invalid code that is not rejected, or poor diagnostics when code is rejected, that is also very important to us.  For make-based projects,
 the <a href="get_started.html#ccc"><code>ccc</code></a> driver works as a drop-in replacement for GCC.</li>
 
-<li><b>Overflow detection</b>: an interesting project would be to add a -ftrapv
-compilation mode that causes -emit-llvm to generate overflow tests for all
-signed integer arithmetic operators, and call abort if they overflow.  Overflow
-is undefined in C and hard for people to reason about.  LLVM IR also has
-intrinsics for generating arithmetic with overflow checks directly.</li>
-
-<li><b>Undefined behavior checking</b>: similar to adding -ftrapv, codegen could
+<li><b>Undefined behavior checking</b>: CodeGen could
 insert runtime checks for all sorts of different undefined behaviors, from 
 reading uninitialized variables, buffer overflows, and many other things.  This
 checking would be expensive, but the optimizers could eliminate many of the 
@@ -58,7 +52,7 @@
 implement capabilities similar to other source language tools, improving them
 in various ways.  Two examples are <a href="http://distcc.samba.org/">distcc</a>
 and the <a href="http://delta.tigris.org/">delta testcase reduction tool</a>.
-The former can be improved to scale better and be more efficient.  The later
+The former can be improved to scale better and be more efficient.  The latter
 could also be faster and more efficient at reducing C-family programs if built
 on the clang preprocessor.</li>
 
@@ -86,12 +80,8 @@
 <li><b>Continue work on C++ support</b>: Implementing all of C++ is a very big
 job, but there are lots of little pieces that can be picked off and implemented. Here are some small- to mid-sized C++ implementation projects:
 <ul>
-  <li>Using declarations: These are completely unsupported at the moment.</li>
-  <li>Type-checking for the conditional operator (? :): this currently follows C semantics, not C++ semantics.</li>
   <li>Type-checking for explicit conversions: currently follows C semantics, not C++ semantics.</li>
-  <li>Type-checking for copy assignment: Clang parses overloaded copy-assignment operators, but they aren't used as part of assignment syntax ("a = b").</li>
   <li>Qualified member references: C++ supports qualified member references such as <code>x->Base::foo</code>, but Clang has no parsing or semantic analysis for them.</li>
-  <li>Virtual functions: Clang parses <code>virtual</code> and attaches it to the AST. However, it does not determine whether a given function overrides a virtual function in a base class.</li>
   <li>Implicit definitions of special member functions: Clang implicitly declares the various special member functions (default constructor, copy constructor, copy assignment operator, destructor) when necessary, but is not yet able to provide definitions for these functions.</li>
   <li>Parsing and AST representations of friend classes and functions</li>
   <li>AST representation for implicit C++ conversions: implicit conversions that involve non-trivial operations (e.g., invoking a user-defined conversion function, performing a base-to-derived or derived-to-base conversion) need explicit representation in Clang's AST.</li>