| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" | |
| "http://www.w3.org/TR/html4/strict.dtd"> | |
| <html> | |
| <head> | |
| <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> | |
| <title>Clang - Get Involved</title> | |
| <link type="text/css" rel="stylesheet" href="menu.css" /> | |
| <link type="text/css" rel="stylesheet" href="content.css" /> | |
| </head> | |
| <body> | |
| <!--#include virtual="menu.html.incl"--> | |
| <div id="content"> | |
| <h1>Getting Involved with the Clang Project</h1> | |
| <p>Once you have <a href="get_started.html">checked out and built</a> clang and | |
| played around with it, you might be wondering what you can do to make it better | |
| and contribute to its development. Alternatively, maybe you just want to follow | |
| the development of the project to see it progress. | |
| </p> | |
| <h2>Follow what's going on</h2> | |
| <p>Clang is a subproject of the <a href="http://llvm.org">LLVM Project</a>, but | |
| has its own mailing lists because the communities have people with different | |
| interests. The two clang lists are:</p> | |
| <ul> | |
| <li><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits">cfe-commits | |
| </a> - This list is for patch submission/discussion.</li> | |
| <li><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">cfe-dev</a> - | |
| This list is for everything else clang related (questions and answers, bug | |
| reports, etc).</li> | |
| </ul> | |
| <p>If you are interested in clang only, these two lists should be all | |
| you need. If you are interested in the LLVM optimizer and code generator, | |
| please consider signing up for <a | |
| href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a> and <a | |
| href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">llvm-commits</a> | |
| as well.</p> | |
| <p>The best way to talk with other developers on the project is through the <a | |
| href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">cfe-dev mailing | |
| list</a>. The clang mailing list is a very friendly place and we welcome | |
| newcomers. In addition to the cfe-dev list, a significant amount of design | |
| discussion takes place on the <a | |
| href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits">cfe-commits mailing | |
| list</a>. All of these lists have archives, so you can browse through previous | |
| discussions or follow the list development on the web if you prefer.</p> | |
| <h2>Open Projects</h2> | |
| <p>Here are a few tasks that are available for newcomers to work on, depending | |
| on what your interests are. This list is provided to generate ideas, it is not | |
| intended to be comprehensive. Please ask on cfe-dev for more specifics or to | |
| verify that one of these isn't already completed. :)</p> | |
| <ul> | |
| <li><b>Compile your favorite C/ObjC project with "clang -fsyntax-only"</b>: | |
| the clang type checker and verifier is quite close to complete (but not bug | |
| free!) for C and Objective C. We appreciate all reports of code that is | |
| rejected by the front-end, and if you notice invalid code that is not rejected | |
| by clang, that is also very important to us. For make-based projects, | |
| the <a href="get_started.html#ccc"><code>ccc</code></a> script in clang's | |
| <tt>utils</tt> folder might help to get you started.</li> | |
| <li><b>Compile your favorite C project with "clang -emit-llvm"</b>: | |
| The clang to LLVM converter is getting more mature, so you may be able to | |
| compile it. If not, please let us know. Again, | |
| <a href="get_started.html#ccc"><code>ccc</code></a> might help you. Once it | |
| compiles it should run. If not, that's a bug :)</li> | |
| <li><b>Work on code generation for Objective C</b>: -emit-llvm support for | |
| Objective C is basically nonexistent at the time of this writing, this is a | |
| nice open project that can be tackled incrementally (one language feature at a | |
| time).</li> | |
| <li><b>Debug Info Generation</b>: -emit-llvm doesn't currently support emission | |
| of <a href="http://llvm.org/docs/SourceLevelDebugging.html">LLVM debug info</a> | |
| (which the code generator turns into DWARF). Adding this should be | |
| straight-forward if you follow the example of what llvm-gcc generates.</li> | |
| <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. | |
| See the <a href="cxx_status.html">C++ status report page</a> to find out what is | |
| missing and what is already at least partially supported.</li> | |
| <li><b>Improve target support</b>: The current target interfaces are heavily | |
| stubbed out and need to be implemented fully. See the FIXME's in TargetInfo. | |
| Additionally, the actual target implementations (instances of TargetInfoImpl) | |
| also need to be completed. This includes defining builtin macros for linux | |
| targets and other stuff like that.</li> | |
| <li><b>Implement 'builtin' headers</b>: GCC provides a bunch of builtin headers, | |
| such as stdbool.h, iso646.h, float.h, limits.h, etc. It also provides a bunch | |
| of target-specific headers like altivec.h and xmmintrin.h. clang will | |
| eventually need to provide its own copies of these (and there is a <a href= | |
| "http://lists.cs.uiuc.edu/pipermail/cfe-dev/2007-December/000560.html">lot of | |
| improvement</a> that can be made to the GCC ones!) that are clean-room | |
| implemented to avoid GPL taint.</li> | |
| <li><b>Implement a clang 'libgcc'</b>: As with the headers, clang (or a another | |
| related subproject of llvm) will need to implement the features that libgcc | |
| provides. libgcc provides a bunch of routines the code generator uses for | |
| "fallback" when the chip doesn't support some operation (e.g. 64-bit divide on | |
| a 32-bit chip). It also provides software floating point support and many other | |
| things. I don't think that there is a specific licensing reason to reimplement | |
| libgcc, but there is a lot of room for improvement in it in many | |
| dimensions.</li> | |
| <li><b>Implement an tool to generate code documentation</b>: Clang's | |
| library-based design allows it to be used by a variety of tools that reason | |
| about source code. One great application of Clang would be to build an | |
| auto-documentation system like doxygen that generates code documentation from | |
| source code. The advantage of using Clang for such a tool is that the tool would | |
| use the same preprocessor/parser/ASTs as the compiler itself, giving it a very | |
| rich understanding of the code.</li> | |
| <li><b>Use clang libraries to implement better versions of existing tools</b>: | |
| Clang is built as a set of libraries, which means that it is possible to | |
| 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 | |
| could also be faster and more efficient at reducing C-family programs if built | |
| on the clang preprocessor.</li> | |
| <li><b>Use clang libraries to extend Ragel with a JIT</b>: <a | |
| href="http://research.cs.queensu.ca/~thurston/ragel/">Ragel</a> is a state | |
| machine compiler that lets you embed C code into state machines and generate | |
| C code. It would be relatively easy to turn this into a JIT compiler using | |
| LLVM.</li> | |
| <li><b>Self-testing using clang</b>: There are several neat ways to | |
| improve the quality of clang by self-testing. Some examples: | |
| <ul> | |
| <li>Improve the reliability of AST printing and serialization by | |
| ensuring that the AST produced by clang on an input doesn't change | |
| when it is reparsed or unserialized. | |
| <li>Improve parser reliability and error generation by automatically | |
| or randomly changing the input checking that clang doesn't crash and | |
| that it doesn't generate excessive errors for small input | |
| changes. Manipulating the input at both the text and token levels is | |
| likely to produce interesting test cases. | |
| </ul> | |
| </li> | |
| </ul> | |
| <p>If you hit a bug with clang, it is very useful for us if you reduce the code | |
| that demonstrates the problem down to something small. There are many ways to | |
| do this; ask on cfe-dev for advice.</p> | |
| </div> | |
| </body> | |
| </html> |