Chris Lattner | ce90ba6 | 2007-12-10 05:20:47 +0000 | [diff] [blame] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" |
| 2 | "http://www.w3.org/TR/html4/strict.dtd"> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 3 | <html> |
| 4 | <head> |
Benjamin Kramer | 665a8dc | 2012-01-15 15:26:07 +0000 | [diff] [blame] | 5 | <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 6 | <title>Clang - Features and Goals</title> |
Benjamin Kramer | 665a8dc | 2012-01-15 15:26:07 +0000 | [diff] [blame] | 7 | <link type="text/css" rel="stylesheet" href="menu.css"> |
| 8 | <link type="text/css" rel="stylesheet" href="content.css"> |
Chris Lattner | ce90ba6 | 2007-12-10 05:20:47 +0000 | [diff] [blame] | 9 | <style type="text/css"> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 10 | </style> |
| 11 | </head> |
| 12 | <body> |
Chris Lattner | ce90ba6 | 2007-12-10 05:20:47 +0000 | [diff] [blame] | 13 | |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 14 | <!--#include virtual="menu.html.incl"--> |
Chris Lattner | ce90ba6 | 2007-12-10 05:20:47 +0000 | [diff] [blame] | 15 | |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 16 | <div id="content"> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 17 | |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 18 | <!--*************************************************************************--> |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 19 | <h1>Clang - Features and Goals</h1> |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 20 | <!--*************************************************************************--> |
| 21 | |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 22 | <p> |
| 23 | This page describes the <a href="index.html#goals">features and goals</a> of |
| 24 | Clang in more detail and gives a more broad explanation about what we mean. |
| 25 | These features are: |
| 26 | </p> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 27 | |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 28 | <p>End-User Features:</p> |
| 29 | |
| 30 | <ul> |
Chris Lattner | de9a4f5 | 2007-12-13 05:42:27 +0000 | [diff] [blame] | 31 | <li><a href="#performance">Fast compiles and low memory use</a></li> |
Chris Lattner | cf086ea | 2007-12-10 08:19:29 +0000 | [diff] [blame] | 32 | <li><a href="#expressivediags">Expressive diagnostics</a></li> |
Chris Lattner | b5604af | 2007-12-10 07:23:52 +0000 | [diff] [blame] | 33 | <li><a href="#gcccompat">GCC compatibility</a></li> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 34 | </ul> |
| 35 | |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 36 | <p>Utility and Applications:</p> |
| 37 | |
| 38 | <ul> |
| 39 | <li><a href="#libraryarch">Library based architecture</a></li> |
| 40 | <li><a href="#diverseclients">Support diverse clients</a></li> |
| 41 | <li><a href="#ideintegration">Integration with IDEs</a></li> |
| 42 | <li><a href="#license">Use the LLVM 'BSD' License</a></li> |
| 43 | </ul> |
| 44 | |
| 45 | <p>Internal Design and Implementation:</p> |
| 46 | |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 47 | <ul> |
| 48 | <li><a href="#real">A real-world, production quality compiler</a></li> |
Chris Lattner | b5604af | 2007-12-10 07:23:52 +0000 | [diff] [blame] | 49 | <li><a href="#simplecode">A simple and hackable code base</a></li> |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 50 | <li><a href="#unifiedparser">A single unified parser for C, Objective C, C++, |
| 51 | and Objective C++</a></li> |
| 52 | <li><a href="#conformance">Conformance with C/C++/ObjC and their |
| 53 | variants</a></li> |
| 54 | </ul> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 55 | |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 56 | <!--*************************************************************************--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 57 | <h2><a name="enduser">End-User Features</a></h2> |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 58 | <!--*************************************************************************--> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 59 | |
| 60 | |
| 61 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 62 | <h3><a name="performance">Fast compiles and Low Memory Use</a></h3> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 63 | <!--=======================================================================--> |
| 64 | |
| 65 | <p>A major focus of our work on clang is to make it fast, light and scalable. |
| 66 | The library-based architecture of clang makes it straight-forward to time and |
| 67 | profile the cost of each layer of the stack, and the driver has a number of |
| 68 | options for performance analysis.</p> |
| 69 | |
| 70 | <p>While there is still much that can be done, we find that the clang front-end |
| 71 | is significantly quicker than gcc and uses less memory For example, when |
| 72 | compiling "Carbon.h" on Mac OS/X, we see that clang is 2.5x faster than GCC:</p> |
| 73 | |
Benjamin Kramer | 665a8dc | 2012-01-15 15:26:07 +0000 | [diff] [blame] | 74 | <img class="img_slide" src="feature-compile1.png" width="400" height="300" |
| 75 | alt="Time to parse carbon.h: -fsyntax-only"> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 76 | |
| 77 | <p>Carbon.h is a monster: it transitively includes 558 files, 12.3M of code, |
| 78 | declares 10000 functions, has 2000 struct definitions, 8000 fields, 20000 enum |
| 79 | constants, etc (see slide 25+ of the <a href="clang_video-07-25-2007.html">clang |
| 80 | talk</a> for more information). It is also #include'd into almost every C file |
| 81 | in a GUI app on the Mac, so its compile time is very important.</p> |
| 82 | |
| 83 | <p>From the slide above, you can see that we can measure the time to preprocess |
| 84 | the file independently from the time to parse it, and independently from the |
| 85 | time to build the ASTs for the code. GCC doesn't provide a way to measure the |
| 86 | parser without AST building (it only provides -fsyntax-only). In our |
| 87 | measurements, we find that clang's preprocessor is consistently 40% faster than |
| 88 | GCCs, and the parser + AST builder is ~4x faster than GCC's. If you have |
| 89 | sources that do not depend as heavily on the preprocessor (or if you |
| 90 | use Precompiled Headers) you may see a much bigger speedup from clang. |
| 91 | </p> |
| 92 | |
| 93 | <p>Compile time performance is important, but when using clang as an API, often |
| 94 | memory use is even moreso: the less memory the code takes the more code you can |
| 95 | fit into memory at a time (useful for whole program analysis tools, for |
| 96 | example).</p> |
| 97 | |
Benjamin Kramer | 665a8dc | 2012-01-15 15:26:07 +0000 | [diff] [blame] | 98 | <img class="img_slide" src="feature-memory1.png" width="400" height="300" |
| 99 | alt="Space"> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 100 | |
| 101 | <p>Here we see a huge advantage of clang: its ASTs take <b>5x less memory</b> |
| 102 | than GCC's syntax trees, despite the fact that clang's ASTs capture far more |
| 103 | source-level information than GCC's trees do. This feat is accomplished through |
| 104 | the use of carefully designed APIs and efficient representations.</p> |
| 105 | |
| 106 | <p>In addition to being efficient when pitted head-to-head against GCC in batch |
| 107 | mode, clang is built with a <a href="#libraryarch">library based |
| 108 | architecture</a> that makes it relatively easy to adapt it and build new tools |
| 109 | with it. This means that it is often possible to apply out-of-the-box thinking |
| 110 | and novel techniques to improve compilation in various ways.</p> |
| 111 | |
Benjamin Kramer | 665a8dc | 2012-01-15 15:26:07 +0000 | [diff] [blame] | 112 | <img class="img_slide" src="feature-compile2.png" width="400" height="300" |
| 113 | alt="Preprocessor Speeds: GCC 4.2 vs clang-all"> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 114 | |
| 115 | <p>This slide shows how the clang preprocessor can be used to make "distcc" |
| 116 | parallelization <b>3x</b> more scalable than when using the GCC preprocessor. |
| 117 | "distcc" quickly bottlenecks on the preprocessor running on the central driver |
| 118 | machine, so a fast preprocessor is very useful. Comparing the first two bars |
| 119 | of each group shows how a ~40% faster preprocessor can reduce preprocessing time |
| 120 | of these large C++ apps by about 40% (shocking!).</p> |
| 121 | |
| 122 | <p>The third bar on the slide is the interesting part: it shows how trivial |
| 123 | caching of file system accesses across invocations of the preprocessor allows |
| 124 | clang to reduce time spent in the kernel by 10x, making distcc over 3x more |
| 125 | scalable. This is obviously just one simple hack, doing more interesting things |
| 126 | (like caching tokens across preprocessed files) would yield another substantial |
| 127 | speedup.</p> |
| 128 | |
| 129 | <p>The clean framework-based design of clang means that many things are possible |
| 130 | that would be very difficult in other systems, for example incremental |
| 131 | compilation, multithreading, intelligent caching, etc. We are only starting |
| 132 | to tap the full potential of the clang design.</p> |
| 133 | |
| 134 | |
| 135 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 136 | <h3><a name="expressivediags">Expressive Diagnostics</a></h3> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 137 | <!--=======================================================================--> |
| 138 | |
Chris Lattner | 13cc235 | 2009-03-19 06:52:51 +0000 | [diff] [blame] | 139 | <p>In addition to being fast and functional, we aim to make Clang extremely user |
| 140 | friendly. As far as a command-line compiler goes, this basically boils down to |
| 141 | making the diagnostics (error and warning messages) generated by the compiler |
Chris Lattner | 9ef3692 | 2009-03-19 22:03:42 +0000 | [diff] [blame] | 142 | be as useful as possible. There are several ways that we do this, but the |
| 143 | most important are pinpointing exactly what is wrong in the program, |
Chris Lattner | 202a742 | 2009-03-19 18:56:04 +0000 | [diff] [blame] | 144 | highlighting related information so that it is easy to understand at a glance, |
| 145 | and making the wording as clear as possible.</p> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 146 | |
Chris Lattner | 202a742 | 2009-03-19 18:56:04 +0000 | [diff] [blame] | 147 | <p>Here is one simple example that illustrates the difference between a typical |
| 148 | GCC and Clang diagnostic:</p> |
Chris Lattner | 13cc235 | 2009-03-19 06:52:51 +0000 | [diff] [blame] | 149 | |
| 150 | <pre> |
| 151 | $ <b>gcc-4.2 -fsyntax-only t.c</b> |
| 152 | t.c:7: error: invalid operands to binary + (have 'int' and 'struct A') |
| 153 | $ <b>clang -fsyntax-only t.c</b> |
| 154 | t.c:7:39: error: invalid operands to binary expression ('int' and 'struct A') |
Benjamin Kramer | 665a8dc | 2012-01-15 15:26:07 +0000 | [diff] [blame] | 155 | <span style="color:darkgreen"> return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X);</span> |
| 156 | <span style="color:blue"> ~~~~~~~~~~~~~~ ^ ~~~~~</span> |
Chris Lattner | 13cc235 | 2009-03-19 06:52:51 +0000 | [diff] [blame] | 157 | </pre> |
| 158 | |
| 159 | <p>Here you can see that you don't even need to see the original source code to |
| 160 | understand what is wrong based on the Clang error: Because clang prints a |
| 161 | caret, you know exactly <em>which</em> plus it is complaining about. The range |
| 162 | information highlights the left and right side of the plus which makes it |
| 163 | immediately obvious what the compiler is talking about, which is very useful for |
Chris Lattner | 9ef3692 | 2009-03-19 22:03:42 +0000 | [diff] [blame] | 164 | cases involving precedence issues and many other situations.</p> |
Chris Lattner | 13cc235 | 2009-03-19 06:52:51 +0000 | [diff] [blame] | 165 | |
Chris Lattner | 9ef3692 | 2009-03-19 22:03:42 +0000 | [diff] [blame] | 166 | <p>Clang diagnostics are very polished and have many features. For more |
Chris Lattner | 202a742 | 2009-03-19 18:56:04 +0000 | [diff] [blame] | 167 | information and examples, please see the <a href="diagnostics.html">Expressive |
| 168 | Diagnostics</a> page.</p> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 169 | |
Chris Lattner | b5604af | 2007-12-10 07:23:52 +0000 | [diff] [blame] | 170 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 171 | <h3><a name="gcccompat">GCC Compatibility</a></h3> |
Chris Lattner | b5604af | 2007-12-10 07:23:52 +0000 | [diff] [blame] | 172 | <!--=======================================================================--> |
| 173 | |
| 174 | <p>GCC is currently the defacto-standard open source compiler today, and it |
| 175 | routinely compiles a huge volume of code. GCC supports a huge number of |
| 176 | extensions and features (many of which are undocumented) and a lot of |
| 177 | code and header files depend on these features in order to build.</p> |
| 178 | |
| 179 | <p>While it would be nice to be able to ignore these extensions and focus on |
| 180 | implementing the language standards to the letter, pragmatics force us to |
| 181 | support the GCC extensions that see the most use. Many users just want their |
| 182 | code to compile, they don't care to argue about whether it is pedantically C99 |
| 183 | or not.</p> |
| 184 | |
| 185 | <p>As mentioned above, all |
| 186 | extensions are explicitly recognized as such and marked with extension |
| 187 | diagnostics, which can be mapped to warnings, errors, or just ignored. |
| 188 | </p> |
| 189 | |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 190 | |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 191 | <!--*************************************************************************--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 192 | <h2><a name="applications">Utility and Applications</a></h2> |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 193 | <!--*************************************************************************--> |
| 194 | |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 195 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 196 | <h3><a name="libraryarch">Library Based Architecture</a></h3> |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 197 | <!--=======================================================================--> |
| 198 | |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 199 | <p>A major design concept for clang is its use of a library-based |
| 200 | architecture. In this design, various parts of the front-end can be cleanly |
| 201 | divided into separate libraries which can then be mixed up for different needs |
| 202 | and uses. In addition, the library-based approach encourages good interfaces |
| 203 | and makes it easier for new developers to get involved (because they only need |
| 204 | to understand small pieces of the big picture).</p> |
| 205 | |
Benjamin Kramer | 665a8dc | 2012-01-15 15:26:07 +0000 | [diff] [blame] | 206 | <blockquote><p> |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 207 | "The world needs better compiler tools, tools which are built as libraries. |
| 208 | This design point allows reuse of the tools in new and novel ways. However, |
| 209 | building the tools as libraries isn't enough: they must have clean APIs, be as |
| 210 | decoupled from each other as possible, and be easy to modify/extend. This |
| 211 | requires clean layering, decent design, and keeping the libraries independent of |
Benjamin Kramer | 665a8dc | 2012-01-15 15:26:07 +0000 | [diff] [blame] | 212 | any specific client."</p></blockquote> |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 213 | |
| 214 | <p> |
| 215 | Currently, clang is divided into the following libraries and tool: |
| 216 | </p> |
| 217 | |
| 218 | <ul> |
| 219 | <li><b>libsupport</b> - Basic support library, from LLVM.</li> |
| 220 | <li><b>libsystem</b> - System abstraction library, from LLVM.</li> |
| 221 | <li><b>libbasic</b> - Diagnostics, SourceLocations, SourceBuffer abstraction, |
| 222 | file system caching for input source files.</li> |
| 223 | <li><b>libast</b> - Provides classes to represent the C AST, the C type system, |
| 224 | builtin functions, and various helpers for analyzing and manipulating the |
| 225 | AST (visitors, pretty printers, etc).</li> |
| 226 | <li><b>liblex</b> - Lexing and preprocessing, identifier hash table, pragma |
| 227 | handling, tokens, and macro expansion.</li> |
| 228 | <li><b>libparse</b> - Parsing. This library invokes coarse-grained 'Actions' |
| 229 | provided by the client (e.g. libsema builds ASTs) but knows nothing about |
| 230 | ASTs or other client-specific data structures.</li> |
| 231 | <li><b>libsema</b> - Semantic Analysis. This provides a set of parser actions |
| 232 | to build a standardized AST for programs.</li> |
| 233 | <li><b>libcodegen</b> - Lower the AST to LLVM IR for optimization & code |
| 234 | generation.</li> |
| 235 | <li><b>librewrite</b> - Editing of text buffers (important for code rewriting |
| 236 | transformation, like refactoring).</li> |
| 237 | <li><b>libanalysis</b> - Static analysis support.</li> |
| 238 | <li><b>clang</b> - A driver program, client of the libraries at various |
| 239 | levels.</li> |
| 240 | </ul> |
| 241 | |
| 242 | <p>As an example of the power of this library based design.... If you wanted to |
| 243 | build a preprocessor, you would take the Basic and Lexer libraries. If you want |
| 244 | an indexer, you would take the previous two and add the Parser library and |
| 245 | some actions for indexing. If you want a refactoring, static analysis, or |
| 246 | source-to-source compiler tool, you would then add the AST building and |
| 247 | semantic analyzer libraries.</p> |
| 248 | |
| 249 | <p>For more information about the low-level implementation details of the |
| 250 | various clang libraries, please see the <a href="docs/InternalsManual.html"> |
| 251 | clang Internals Manual</a>.</p> |
| 252 | |
| 253 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 254 | <h3><a name="diverseclients">Support Diverse Clients</a></h3> |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 255 | <!--=======================================================================--> |
| 256 | |
| 257 | <p>Clang is designed and built with many grand plans for how we can use it. The |
| 258 | driving force is the fact that we use C and C++ daily, and have to suffer due to |
| 259 | a lack of good tools available for it. We believe that the C and C++ tools |
| 260 | ecosystem has been significantly limited by how difficult it is to parse and |
| 261 | represent the source code for these languages, and we aim to rectify this |
| 262 | problem in clang.</p> |
| 263 | |
| 264 | <p>The problem with this goal is that different clients have very different |
| 265 | requirements. Consider code generation, for example: a simple front-end that |
| 266 | parses for code generation must analyze the code for validity and emit code |
| 267 | in some intermediate form to pass off to a optimizer or backend. Because |
| 268 | validity analysis and code generation can largely be done on the fly, there is |
| 269 | not hard requirement that the front-end actually build up a full AST for all |
| 270 | the expressions and statements in the code. TCC and GCC are examples of |
| 271 | compilers that either build no real AST (in the former case) or build a stripped |
| 272 | down and simplified AST (in the later case) because they focus primarily on |
| 273 | codegen.</p> |
| 274 | |
| 275 | <p>On the opposite side of the spectrum, some clients (like refactoring) want |
| 276 | highly detailed information about the original source code and want a complete |
| 277 | AST to describe it with. Refactoring wants to have information about macro |
| 278 | expansions, the location of every paren expression '(((x)))' vs 'x', full |
| 279 | position information, and much more. Further, refactoring wants to look |
| 280 | <em>across the whole program</em> to ensure that it is making transformations |
| 281 | that are safe. Making this efficient and getting this right requires a |
| 282 | significant amount of engineering and algorithmic work that simply are |
| 283 | unnecessary for a simple static compiler.</p> |
| 284 | |
| 285 | <p>The beauty of the clang approach is that it does not restrict how you use it. |
| 286 | In particular, it is possible to use the clang preprocessor and parser to build |
| 287 | an extremely quick and light-weight on-the-fly code generator (similar to TCC) |
| 288 | that does not build an AST at all. As an intermediate step, clang supports |
| 289 | using the current AST generation and semantic analysis code and having a code |
| 290 | generation client free the AST for each function after code generation. Finally, |
| 291 | clang provides support for building and retaining fully-fledged ASTs, and even |
| 292 | supports writing them out to disk.</p> |
| 293 | |
| 294 | <p>Designing the libraries with clean and simple APIs allows these high-level |
| 295 | policy decisions to be determined in the client, instead of forcing "one true |
| 296 | way" in the implementation of any of these libraries. Getting this right is |
| 297 | hard, and we don't always get it right the first time, but we fix any problems |
| 298 | when we realize we made a mistake.</p> |
| 299 | |
| 300 | <!--=======================================================================--> |
Benjamin Kramer | 665a8dc | 2012-01-15 15:26:07 +0000 | [diff] [blame] | 301 | <h3 id="ideintegration">Integration with IDEs</h3> |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 302 | <!--=======================================================================--> |
| 303 | |
| 304 | <p> |
| 305 | We believe that Integrated Development Environments (IDE's) are a great way |
| 306 | to pull together various pieces of the development puzzle, and aim to make clang |
| 307 | work well in such an environment. The chief advantage of an IDE is that they |
| 308 | typically have visibility across your entire project and are long-lived |
| 309 | processes, whereas stand-alone compiler tools are typically invoked on each |
| 310 | individual file in the project, and thus have limited scope.</p> |
| 311 | |
| 312 | <p>There are many implications of this difference, but a significant one has to |
| 313 | do with efficiency and caching: sharing an address space across different files |
| 314 | in a project, means that you can use intelligent caching and other techniques to |
| 315 | dramatically reduce analysis/compilation time.</p> |
| 316 | |
| 317 | <p>A further difference between IDEs and batch compiler is that they often |
| 318 | impose very different requirements on the front-end: they depend on high |
| 319 | performance in order to provide a "snappy" experience, and thus really want |
| 320 | techniques like "incremental compilation", "fuzzy parsing", etc. Finally, IDEs |
| 321 | often have very different requirements than code generation, often requiring |
| 322 | information that a codegen-only frontend can throw away. Clang is |
| 323 | specifically designed and built to capture this information. |
| 324 | </p> |
| 325 | |
| 326 | |
| 327 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 328 | <h3><a name="license">Use the LLVM 'BSD' License</a></h3> |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 329 | <!--=======================================================================--> |
| 330 | |
Chris Lattner | 81921cc | 2010-11-14 07:30:46 +0000 | [diff] [blame] | 331 | <p>We actively intend for clang (and LLVM as a whole) to be used for |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 332 | commercial projects, and the BSD license is the simplest way to allow this. We |
| 333 | feel that the license encourages contributors to pick up the source and work |
| 334 | with it, and believe that those individuals and organizations will contribute |
| 335 | back their work if they do not want to have to maintain a fork forever (which is |
| 336 | time consuming and expensive when merges are involved). Further, nobody makes |
| 337 | money on compilers these days, but many people need them to get bigger goals |
| 338 | accomplished: it makes sense for everyone to work together.</p> |
| 339 | |
| 340 | <p>For more information about the LLVM/clang license, please see the <a |
| 341 | href="http://llvm.org/docs/DeveloperPolicy.html#license">LLVM License |
| 342 | Description</a> for more information.</p> |
| 343 | |
| 344 | |
| 345 | |
| 346 | <!--*************************************************************************--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 347 | <h2><a name="design">Internal Design and Implementation</a></h2> |
Chris Lattner | ead27db | 2007-12-10 08:12:49 +0000 | [diff] [blame] | 348 | <!--*************************************************************************--> |
| 349 | |
Chris Lattner | 1a380a0 | 2007-12-10 07:14:08 +0000 | [diff] [blame] | 350 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 351 | <h3><a name="real">A real-world, production quality compiler</a></h3> |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 352 | <!--=======================================================================--> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 353 | |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 354 | <p> |
Chris Lattner | cddb2af | 2007-12-10 18:56:37 +0000 | [diff] [blame] | 355 | Clang is designed and built by experienced compiler developers who |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 356 | are increasingly frustrated with the problems that <a |
| 357 | href="comparison.html">existing open source compilers</a> have. Clang is |
| 358 | carefully and thoughtfully designed and built to provide the foundation of a |
| 359 | whole new generation of C/C++/Objective C development tools, and we intend for |
Chris Lattner | cddb2af | 2007-12-10 18:56:37 +0000 | [diff] [blame] | 360 | it to be production quality.</p> |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 361 | |
| 362 | <p>Being a production quality compiler means many things: it means being high |
| 363 | performance, being solid and (relatively) bug free, and it means eventually |
| 364 | being used and depended on by a broad range of people. While we are still in |
| 365 | the early development stages, we strongly believe that this will become a |
| 366 | reality.</p> |
| 367 | |
| 368 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 369 | <h3><a name="simplecode">A simple and hackable code base</a></h3> |
Chris Lattner | b5604af | 2007-12-10 07:23:52 +0000 | [diff] [blame] | 370 | <!--=======================================================================--> |
| 371 | |
| 372 | <p>Our goal is to make it possible for anyone with a basic understanding |
| 373 | of compilers and working knowledge of the C/C++/ObjC languages to understand and |
| 374 | extend the clang source base. A large part of this falls out of our decision to |
| 375 | make the AST mirror the languages as closely as possible: you have your friendly |
| 376 | if statement, for statement, parenthesis expression, structs, unions, etc, all |
| 377 | represented in a simple and explicit way.</p> |
| 378 | |
| 379 | <p>In addition to a simple design, we work to make the source base approachable |
| 380 | by commenting it well, including citations of the language standards where |
| 381 | appropriate, and designing the code for simplicity. Beyond that, clang offers |
| 382 | a set of AST dumpers, printers, and visualizers that make it easy to put code in |
| 383 | and see how it is represented.</p> |
| 384 | |
| 385 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 386 | <h3><a name="unifiedparser">A single unified parser for C, Objective C, C++, |
| 387 | and Objective C++</a></h3> |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 388 | <!--=======================================================================--> |
| 389 | |
| 390 | <p>Clang is the "C Language Family Front-end", which means we intend to support |
| 391 | the most popular members of the C family. We are convinced that the right |
| 392 | parsing technology for this class of languages is a hand-built recursive-descent |
| 393 | parser. Because it is plain C++ code, recursive descent makes it very easy for |
| 394 | new developers to understand the code, it easily supports ad-hoc rules and other |
| 395 | strange hacks required by C/C++, and makes it straight-forward to implement |
| 396 | excellent diagnostics and error recovery.</p> |
| 397 | |
| 398 | <p>We believe that implementing C/C++/ObjC in a single unified parser makes the |
| 399 | end result easier to maintain and evolve than maintaining a separate C and C++ |
| 400 | parser which must be bugfixed and maintained independently of each other.</p> |
| 401 | |
| 402 | <!--=======================================================================--> |
Ted Kremenek | 3b61b15 | 2008-06-17 06:35:36 +0000 | [diff] [blame] | 403 | <h3><a name="conformance">Conformance with C/C++/ObjC and their |
| 404 | variants</a></h3> |
Chris Lattner | 6908f30 | 2007-12-10 05:52:05 +0000 | [diff] [blame] | 405 | <!--=======================================================================--> |
| 406 | |
| 407 | <p>When you start work on implementing a language, you find out that there is a |
| 408 | huge gap between how the language works and how most people understand it to |
| 409 | work. This gap is the difference between a normal programmer and a (scary? |
| 410 | super-natural?) "language lawyer", who knows the ins and outs of the language |
| 411 | and can grok standardese with ease.</p> |
| 412 | |
| 413 | <p>In practice, being conformant with the languages means that we aim to support |
| 414 | the full language, including the dark and dusty corners (like trigraphs, |
| 415 | preprocessor arcana, C99 VLAs, etc). Where we support extensions above and |
| 416 | beyond what the standard officially allows, we make an effort to explicitly call |
| 417 | this out in the code and emit warnings about it (which are disabled by default, |
| 418 | but can optionally be mapped to either warnings or errors), allowing you to use |
| 419 | clang in "strict" mode if you desire.</p> |
| 420 | |
| 421 | <p>We also intend to support "dialects" of these languages, such as C89, K&R |
| 422 | C, C++'03, Objective-C 2, etc.</p> |
| 423 | |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 424 | </div> |
| 425 | </body> |
Chris Lattner | bafc68f | 2007-10-06 05:48:57 +0000 | [diff] [blame] | 426 | </html> |