1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
<!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/Driver/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>Complete support for the experimental constant expression interpreter
</b>: 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 <a href="https://clang.llvm.org/docs/ConstantInterpreter.html">
experimental constant expression interpreter</a> 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.
</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, 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>,
or <a href="https://llvm.org/docs/GettingInvolved.html#irc"IRC</a> for advice.</p>
</div>
</body>
</html>
|
