forked from OSchip/llvm-project
129 lines
5.6 KiB
HTML
Executable File
129 lines
5.6 KiB
HTML
Executable File
<!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>
|