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
| <!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=ISO-8859-1">
<title>Clang - Get Involved</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>Getting Involved with the Clang Project</h1>
<p>Once you have <a href="get_started.html">checked out and built</a> 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.
</p>
<h2>Contribute</h2>
See the <a href="hacking.html">hacking</a> document for information on how
to author patches.
<h2>Follow what's going on</h2>
<p>Clang is a subproject of the <a href="https://llvm.org">LLVM Project</a>, but
has its own mailing lists because the communities have people with different
interests. The two clang lists are:</p>
<ul>
<li><a href="https://lists.llvm.org/mailman/listinfo/cfe-commits">cfe-commits
</a> - This list is for patch submission/discussion.</li>
<li><a href="https://lists.llvm.org/mailman/listinfo/cfe-dev">cfe-dev</a> -
This list is for everything else Clang related (questions and answers, design
discussions, etc).</li>
</ul>
<p>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 <a
href="https://lists.llvm.org/mailman/listinfo/llvm-dev">llvm-dev</a> and <a
href="https://lists.llvm.org/mailman/listinfo/llvm-commits">llvm-commits</a>
as well.</p>
<p>The most common way to talk with other developers on the project is through
the <a href="https://lists.llvm.org/mailman/listinfo/cfe-dev">cfe-dev mailing
list</a>. 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 <a
href="https://lists.llvm.org/mailman/listinfo/cfe-commits">cfe-commits mailing
list</a>. All of these lists have archives, so you can browse through previous
discussions or follow the list development on the web if you prefer.</p>
<p>You can also follow the <a href="http://planet.clang.org/">Planet Clang</a>
community news feed which offers a window into the world, work and lives of
Clang developers, contributors and the standards they implement.</p>
<p>If you're looking for something to work on, check out our <a
href="OpenProjects.html">Open Projects</a> page or look through the <a
href="https://bugs.llvm.org/">Bugzilla bug database</a>.</p>
<h2 id="criteria">Contributing Extensions to Clang</h2>
<p>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:</p>
<ol>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ol>
</div>
</body>
</html>
|