www/OpenProjects.html - platform/external/clang - Gitiles

 <!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>Open Clang Projects</h1>

 <p>Here are a few tasks that are available for newcomers 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 cfe-dev for more specifics or to
 verify that one of these isn't already completed. :)</p>

 <ul>
 <li><b>Undefined behavior checking</b>:
 Improve and extend the runtime checks for undefined behavior which CodeGen
 inserts for the various <tt>-fsanitize=</tt> modes. A lot of issues can already
 be caught, but there is more to do here.</li>

 <li><b>Improve target support</b>: The current target interfaces are heavily
 stubbed out and need to be implemented fully.  See the FIXME's in TargetInfo.
 Additionally, the actual target implementations (instances of TargetInfoImpl)
 also need to be completed.</li>

 <li><b>Implement an tool to generate code documentation</b>: Clang's
 library-based design allows it to be used by a variety of tools that reason
 about source code. One great application of Clang would be to build an
 auto-documentation system like doxygen that generates code documentation from
 source code. The advantage of using Clang for such a tool is that the tool would
 use the same preprocessor/parser/ASTs as the compiler itself, giving it a very
 rich understanding of the code. Clang is already able to read and understand
 doxygen markup, but cannot yet generate documentation from it.</li>

 <li><b>Use clang libraries to implement better versions of existing tools</b>:
 Clang is built as a set of libraries, which means that it is possible to
 implement capabilities similar to other source language tools, improving them
 in various ways.  Three examples are <a
 href="http://distcc.samba.org/">distcc</a>, the <a
 href="http://delta.tigris.org/">delta testcase reduction tool</a>, and the
 "indent" source reformatting tool.
 distcc can be improved to scale better and be more efficient.  Delta could be
 faster and more efficient at reducing C-family programs if built on the clang
 preprocessor. The clang-based indent replacement,
 <a href="http://clang.llvm.org/docs/ClangFormat.html">clang-format</a>,
 could be taught to handle simple structural rules like those in <a
 href="http://llvm.org/docs/CodingStandards.html#hl_earlyexit">the LLVM coding
 standards</a>.</li>

 <li><b>Use clang libraries to extend Ragel with a JIT</b>: <a
 href="http://research.cs.queensu.ca/~thurston/ragel/">Ragel</a> is a state
 machine compiler that lets you embed C code into state machines and generate
 C code.  It would be relatively easy to turn this into a JIT compiler using
 LLVM.</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++1y support</b>:
   C++98 and C++11 are feature-complete, but there are still several C++1y features to
   implement.  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>Universal Driver</b>: Clang is inherently a cross compiler. We would like
 to define a new model for cross compilation which provides a great user
 experience -- it should be easy to cross compile applications, install support
 for new architectures, access different compilers and tools, and be consistent
 across different platforms. See the <a href="UniversalDriver.html">Universal
 Driver</a> web page for more information.</li>

 <li><b>XML Representation of ASTs</b>: Clang maintains a rich Abstract Syntax Tree that describes the program. Clang could emit an XML document that describes the program, which others tools could consume rather than being tied directly to the Clang binary.The XML representation needs to meet several requirements:
   <ul>
     <li><i>General</i>, so that it's able to represent C/C++/Objective-C abstractly, and isn't tied to the specific internal ASTs that Clang uses.</li>
     <li><i>Documented</i>, with appropriate Schema against which the output of Clang's XML formatter can be verified.</li>
     <li><i>Stable</i> across Clang versions.</li>
   </ul></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 chosing 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 greatle 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>
 </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 cfe-dev for advice.</p>

 </div>
 </body>
 </html>
	<!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>Open Clang Projects</h1>

	<p>Here are a few tasks that are available for newcomers 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 cfe-dev for more specifics or to
	verify that one of these isn't already completed. :)</p>

	<ul>
	<li><b>Undefined behavior checking</b>:
	Improve and extend the runtime checks for undefined behavior which CodeGen
	inserts for the various <tt>-fsanitize=</tt> modes. A lot of issues can already
	be caught, but there is more to do here.</li>

	<li><b>Improve target support</b>: The current target interfaces are heavily
	stubbed out and need to be implemented fully. See the FIXME's in TargetInfo.
	Additionally, the actual target implementations (instances of TargetInfoImpl)
	also need to be completed.</li>

	<li><b>Implement an tool to generate code documentation</b>: Clang's
	library-based design allows it to be used by a variety of tools that reason
	about source code. One great application of Clang would be to build an
	auto-documentation system like doxygen that generates code documentation from
	source code. The advantage of using Clang for such a tool is that the tool would
	use the same preprocessor/parser/ASTs as the compiler itself, giving it a very
	rich understanding of the code. Clang is already able to read and understand
	doxygen markup, but cannot yet generate documentation from it.</li>

	<li><b>Use clang libraries to implement better versions of existing tools</b>:
	Clang is built as a set of libraries, which means that it is possible to
	implement capabilities similar to other source language tools, improving them
	in various ways. Three examples are <a
	href="http://distcc.samba.org/">distcc</a>, the <a
	href="http://delta.tigris.org/">delta testcase reduction tool</a>, and the
	"indent" source reformatting tool.
	distcc can be improved to scale better and be more efficient. Delta could be
	faster and more efficient at reducing C-family programs if built on the clang
	preprocessor. The clang-based indent replacement,
	<a href="http://clang.llvm.org/docs/ClangFormat.html">clang-format</a>,
	could be taught to handle simple structural rules like those in <a
	href="http://llvm.org/docs/CodingStandards.html#hl_earlyexit">the LLVM coding
	standards</a>.</li>

	<li><b>Use clang libraries to extend Ragel with a JIT</b>: <a
	href="http://research.cs.queensu.ca/~thurston/ragel/">Ragel</a> is a state
	machine compiler that lets you embed C code into state machines and generate
	C code. It would be relatively easy to turn this into a JIT compiler using
	LLVM.</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++1y support</b>:
	C++98 and C++11 are feature-complete, but there are still several C++1y features to
	implement. 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>Universal Driver</b>: Clang is inherently a cross compiler. We would like
	to define a new model for cross compilation which provides a great user
	experience -- it should be easy to cross compile applications, install support
	for new architectures, access different compilers and tools, and be consistent
	across different platforms. See the <a href="UniversalDriver.html">Universal
	Driver</a> web page for more information.</li>

	<li><b>XML Representation of ASTs</b>: Clang maintains a rich Abstract Syntax Tree that describes the program. Clang could emit an XML document that describes the program, which others tools could consume rather than being tied directly to the Clang binary.The XML representation needs to meet several requirements:
	<ul>
	<li><i>General</i>, so that it's able to represent C/C++/Objective-C abstractly, and isn't tied to the specific internal ASTs that Clang uses.</li>
	<li><i>Documented</i>, with appropriate Schema against which the output of Clang's XML formatter can be verified.</li>
	<li><i>Stable</i> across Clang versions.</li>
	</ul></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 chosing 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 greatle 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>
	</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 cfe-dev for advice.</p>

	</div>
	</body>
	</html>