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.

Contribute

See the hacking document for information on how to author patches.

Follow what's going on

Clang is a subproject of the LLVM Project and has a Discourse forum and mailing list:

The most common way to talk with other developers on the project is through the Clang Frontend Discourse forum . The clang forum is a very friendly place and we welcome newcomers. In addition to the forum, 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.

If you're looking for something to work on, check out our Open Projects page or look through the LLVM bug tracker.

Contributing Extensions to Clang

Clang is designed to support experimentation, allowing programmers to easily extend the compiler to support great new language features and tools. At some point, the authors of these extensions may propose that the extensions become a part of Clang itself, to benefit the whole Clang community. However, extensions (particularly language extensions) have long-term maintenance costs for Clang. The benefits of the extension need to be evaluated against these costs. The Clang project uses the following criteria for this evaluation:

  1. Evidence of a significant user community: This is based on a number of factors, including an existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any secondary effects that come from, e.g., a library adopting the feature and providing benefits to its users.
  2. A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project.
  3. A specification: The specification must be sufficient to understand the design of the feature as well as interpret the meaning of specific examples. The specification should be detailed enough that another compiler vendor could implement the feature.
  4. Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. This criterion does not apply to all extensions, since some extensions fall outside of the realm of the standards bodies.
  5. A long-term support plan: increasingly large or complex extensions to Clang need matching commitments to supporting them over time, including improving their implementation and specification as Clang evolves. The capacity of the contributor to make that commitment is as important as the commitment itself.
  6. A high-quality implementation: The implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including diagnostics and complete AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler.
  7. A test suite: Extensive testing is crucial to ensure that the language extension is not broken by ongoing maintenance in Clang. The test suite should be complete enough that another compiler vendor could conceivably validate their implementation of the feature against it.