Getting Involved with the Clang Project

Once you have checked out and built 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.

Follow what's going on

Clang is a subproject of the LLVM Project, but has its own mailing lists because the communities have people with different interests. The two clang lists are:

• cfe-commits - This list is for patch submission/discussion.
• cfe-dev - This list is for everything else clang related (questions and answers, bug reports, etc).

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 llvmdev and llvm-commits as well.

The best way to talk with other developers on the project is through the cfe-dev mailing list. 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 cfe-commits mailing list. All of these lists have archives, so you can browse through previous discussions or follow the list development on the web if you prefer.

Open Projects

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. :)

• Compile your favorite C/ObjC project with "clang -fsyntax-only": 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.
• Compile your favorite C project with "clang -emit-llvm": The clang to LLVM converter is getting more mature, so you may be able to compile it. If not, please let us know. Once it compiles it should run. If not, that's a bug :)
• Working on code generation for Objective C: -emit-llvm support for Objective C is basically non-existant at the time of this writing, this is a nice open project that can be tackled incrementally (one language feature at a time).
• Continue work on C++ support: Implementing all of C++ is a very big job, but there are lots of little things that can be done. Right now we support some small things like references and bool. We also support parsing of namespaces, but don't build ASTs for it. It would be straight-forward to implement support for representing namespaces, then add support for things like foo::bar::baz. Likewise, lots of other little pieces can be picked off and implemented.
• Improve target support: 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.
• Implement 'builtin' headers: 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 lot of improvement that can be made to the GCC ones!) that are clean-room implemented to avoid GPL taint.
• Implement a clang 'libgcc': 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.

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.