| <!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=utf-8"> | |
| <title>Clang - Open Projects</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>Open Clang Projects</h1> | |
| <p>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 | |
| <a href="https://discourse.llvm.org/c/clang">Discourse</a> for more specifics | |
| or to verify that one of these isn't already completed.</p> | |
| <ul> | |
| <li><b>Refresh and improve Clang's documentation</b>: Clang is inconsistent | |
| with documenting implementation-defined behaviors. We have significant | |
| documentation in the <a href="https://clang.llvm.org/docs/LanguageExtensions.html"> | |
| Language Extensions</a> page, but the information is incomplete and the page is | |
| difficult to navigate. We would appreciate help with: | |
| <ul> | |
| <li>improving the way this information is presented to users,</li> | |
| <li><a href="https://llvm.org/docs/TableGen/">table generating</a> | |
| documentation where possible, such as for implementation limits or other | |
| target-specific information,</li> | |
| <li>adding documentation for currently | |
| <a href="https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/AttrDocs.td"> | |
| undocumented attributes</a>,</li> | |
| <li>documenting <a href="https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/DiagnosticDocs.td"> | |
| diagnostic group flags</a> (adding code examples of what is diagnosed, or | |
| other relevant information), or</li> | |
| <li>documenting <a href="https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Options/Options.td"> | |
| command line options</a>, or</li> | |
| <li>help with completing other missing documentation.</li> | |
| </ul> | |
| These projects are independent of each other.</li> | |
| <li><b>Complete the investigation into Clang's C conformance</b>: Clang's | |
| <a href="c_status.html">C status page</a> contain a number of entries marked as | |
| <code>Unknown</code>. Completing the investigation involves adding | |
| <a href="https://github.com/llvm/llvm-project/tree/main/clang/test/C">test | |
| coverage</a> for the various standards papers and updating the documentation | |
| accordingly. | |
| </li> | |
| <li><b>Improve Clang's C and C++ standard conformance test coverage</b>: | |
| 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 <code>clang/test/Parser</code>, and semantic analysis | |
| tests in <code>clang/test/Sema*</code>, etc. We also have tests written to | |
| provide coverage for the standard requirements (<code>clang/test/CXX</code> and | |
| <code>clang/test/C</code>). 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.</li> | |
| <li><b>Complete the investigation into Clang's C and C++ Defect Report | |
| conformance</b>: Separate from (but related to) general conformance testing is | |
| determining which <a href="c_dr_status.html">C defect reports</a> and | |
| <a href="cxx_dr_status.html">C++ defect reports</a> Clang implements. These | |
| lists currently have a number of entries marked as <code>Unknown</code>. | |
| Completing the investigation involves adding test coverage for | |
| <a href="https://github.com/llvm/llvm-project/tree/main/clang/test/C/drs">C</a> | |
| and | |
| <a href="https://github.com/llvm/llvm-project/tree/main/clang/test/CXX/drs">C++</a> | |
| defect reports and updating the documentation accordingly.</li> | |
| <li><b>Bug triage</b>: Clang's <a href="https://github.com/llvm/llvm-project/issues"> | |
| issue tracker</a>currently 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 | |
| <a href="https://llvm.org/docs/BugLifeCycle.html#triaging-bugs">bug triage and | |
| issue tracker maintenance</a>. | |
| </li> | |
| <li><b>Improve build times with Clang</b>: 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.</li> | |
| <li><b>Improve clang-doc</b>: Clang's library-based design allows it to be used | |
| by a variety of tools that reason about source code. | |
| <a href="https://clang.llvm.org/extra/clang-doc.html">clang-doc</a> 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.</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> | |
| <li><b>Continue work on C++20, C++23, C++2c, C++2d, and C23 support</b>: | |
| There are still several C++20 features to complete, and work has begun on | |
| supporting the latest language standards. Please see the | |
| <a href="cxx_status.html">C++ status report page</a> to find out what is | |
| missing.</li> | |
| <li><b>StringRef'ize APIs</b>: A thankless but incredibly useful project is | |
| StringRef'izing (converting to use <tt>llvm::StringRef</tt> instead of <tt>const | |
| char *</tt> or <tt>std::string</tt>) various clang interfaces. This generally | |
| simplifies the code and makes it more efficient.</li> | |
| <li><b>Configuration Manager</b>: 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. | |
| <p>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.</p> | |
| <p>The first stage is to build a CFLAGS for Clang that would produce code on the | |
| current Host to the identified Target.</p> | |
| <p>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.</p></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 <a href="https://discourse.llvm.org/c/clang">Discourse</a>, | |
| <a href="https://discord.com/channels/636084430946959380/636725486533345280">Discord</a> | |
| (<a href="https://discord.gg/xS7Z362">invite link</a>) for advice.</p> | |
| </div> | |
| </body> | |
| </html> |