Open Clang Projects

Here are a few tasks that are available for anyone 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 Discourse for more specifics or to verify that one of these isn't already completed.

• Refresh and improve Clang's documentation: Clang is inconsistent with documenting implementation-defined behaviors. We have significant documentation in the Language Extensions page, but the information is incomplete and the page is difficult to navigate. We would appreciate help with:
  • improving the way this information is presented to users,
  • table generating documentation where possible, such as for implementation limits or other target-specific information,
  • adding documentation for currently undocumented attributes,
  • documenting diagnostic group flags (adding code examples of what is diagnosed, or other relevant information), or
  • documenting command line options, or
  • help with completing other missing documentation.
  These projects are independent of each other.
• Complete the investigation into Clang's C conformance: Clang's C status page contain a number of entries marked as Unknown. Completing the investigation involves adding test coverage for the various standards papers and updating the documentation accordingly.
• Improve Clang's C and C++ standard conformance test coverage: Clang's test suite is structured such that most tests are written to provide coverage for what part of the compiler the feature's implementation exists in; we have parsing tests in clang/test/Parser, and semantic analysis tests in clang/test/Sema*, etc. We also have tests written to provide coverage for the standard requirements (clang/test/CXX and clang/test/C). The standards coverage is not structured in a way that makes it easy to maintain as the standards change over time. No commercial conformance test suite has a license model suitable for open source projects, so we would appreciate help in improving the existing coverage we have both in terms of layout of the tests as well as in coverage of the various standard modes.
• Complete the investigation into Clang's C and C++ Defect Report conformance: Separate from (but related to) general conformance testing is determining which C defect reports and C++ defect reports Clang implements. These lists currently have a number of entries marked as Unknown. Completing the investigation involves adding test coverage for C and C++ defect reports and updating the documentation accordingly.
• Bug triage: Clang's issue trackercurrently has over 20,000 open issues, many of which are not appropriately tagged, are no longer reproducible, could use a reduced test case, or otherwise needs some manual interaction. We can always use help with bug triage and issue tracker maintenance.
• Improve build times with Clang: the time it takes Clang to process a translation unit is very important to our users; the lower the build time, the better the overall user experience. It would be good to improve Clang's performance as well as to find ways to proactively alert us when we've introduced a change that has significant negative impact on build times.
• Complete support for the experimental constant expression interpreter : Clang's production constant expression interpreter computes a constant expression result by walking over AST nodes, performing calculations as it goes. This does not have good performance properties, and so we've begun work on an experimental constant expression interpreter that works by converting the AST into bytecode that is interpreted. This effort has a long tail of work left to complete because it requires implementing byte code for every kind of expression and type that can be used in a constant expression for C++ and C.
• Improve clang-doc: Clang's library-based design allows it to be used by a variety of tools that reason about source code. clang-doc is one great application of this functionality, which generates code documentation from source code. The tool is in early stages of development and could use more dedicated effort to complete the implementation.
• Self-testing using clang: There are several neat ways to improve the quality of clang by self-testing. Some examples:
  • 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.
  • 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.
• Continue work on C++20, C++23, C++2c, and C23 support: There are still several C++20 features to complete, and work has begun on supporting the latest language standards. Please see the C++ status report page to find out what is missing.
• StringRef'ize APIs: A thankless but incredibly useful project is StringRef'izing (converting to use llvm::StringRef instead of const char * or std::string) various clang interfaces. This generally simplifies the code and makes it more efficient.
• Configuration Manager: Clang/LLVM works on a large number of architectures and operating systems and can cross-compile to a similarly large number of configurations, but the pitfalls of choosing the command-line options, making sure the right sub-architecture is chosen and that the correct optional elements of your particular system can be a pain.

  A tool that would investigate hosts and targets, and store the configuration in files that can later be used by Clang itself to avoid command-line options, especially the ones regarding which target options to use, would greatly alleviate this problem. A simple tool, with little or no dependency on LLVM itself, that will investigate a target architecture by probing hardware, software, libraries and compiling and executing code to identify all properties that would be relevant to command-line options (VFP, SSE, NEON, ARM vs. Thumb etc), triple settings etc.

  The first stage is to build a CFLAGS for Clang that would produce code on the current Host to the identified Target.

  The second stage would be to produce a configuration file (that can be used independently of the Host) so that Clang can read it and not need a gazillion of command-line options. Such file should be simple JSON / INI or anything that a text editor could change.

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 Discourse, Discord, or for advice.