From: Chris Lattner <sabre@nondot.org>
Date: Mon, 10 Dec 2007 07:23:52 +0000 (+0000)
Subject: now with hackability.
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=b5604af3066fdb86ff4d7511b28e98af2780a39a;p=clang

now with hackability.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@44784 91177308-0d34-0410-b5e6-96231b3b80d8
---

diff --git a/www/comparison.html b/www/comparison.html
index 40cf546233..78261b7cce 100644
--- a/www/comparison.html
+++ b/www/comparison.html
@@ -60,7 +60,8 @@
     <p>Pro's of clang vs GCC:</p>
     
     <ul>
-    <li>The Clang ASTs and design are intended to be easily understandable to
+    <li>The Clang ASTs and design are intended to be <a 
+        href="features.html#simplecode">easily understandable</a> by
         anyone who is familiar with the languages involved and who have a basic
         understanding of how a compiler works.  GCC has a very old codebase
         which presents a steep learning curve to new developers.</li>
diff --git a/www/features.html b/www/features.html
index 79439f8785..91ebf43183 100644
--- a/www/features.html
+++ b/www/features.html
@@ -27,16 +27,17 @@ These features are:
 <ul>
 <li><a href="#performance">High Performance and Low Memory Use</a></li>
 <li><a href="#expressivediags">Expressive Diagnostics</a></a></li>
+<li><a href="#gcccompat">GCC compatibility</a></li>
 </ul>
 
 <p>Driving Goals and Internal Design:</p>
 <ul>
 <li><a href="#real">A real-world, production quality compiler</a></li>
+<li><a href="#simplecode">A simple and hackable code base</a></li>
 <li><a href="#unifiedparser">A single unified parser for C, Objective C, C++,
     and Objective C++</a></li>
 <li><a href="#conformance">Conformance with C/C++/ObjC and their
     variants</a></li>
-<li><a href="#gcccompat">GCC compatibility</a></li>
 </ul>
 
 <!--=======================================================================-->
@@ -147,6 +148,26 @@ std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;</tt>"!), but it is
 also very useful in C code in some cases as well (e.g. "<tt>__m128"</tt> vs
 "<tt>float __attribute__((__vector_size__(16)))</tt>").</p>
 
+<!--=======================================================================-->
+<h2><a name="gcccompat">GCC Compatibility</a></h2>
+<!--=======================================================================-->
+
+<p>GCC is currently the defacto-standard open source compiler today, and it
+routinely compiles a huge volume of code.  GCC supports a huge number of
+extensions and features (many of which are undocumented) and a lot of 
+code and header files depend on these features in order to build.</p>
+
+<p>While it would be nice to be able to ignore these extensions and focus on
+implementing the language standards to the letter, pragmatics force us to
+support the GCC extensions that see the most use.  Many users just want their
+code to compile, they don't care to argue about whether it is pedantically C99
+or not.</p>
+
+<p>As mentioned above, all
+extensions are explicitly recognized as such and marked with extension
+diagnostics, which can be mapped to warnings, errors, or just ignored.
+</p>
+
 
 <!--=======================================================================-->
 <h1>Driving Goals and Internal Design</h1>
@@ -170,6 +191,23 @@ being used and depended on by a broad range of people.  While we are still in
 the early development stages, we strongly believe that this will become a
 reality.</p>
 
+<!--=======================================================================-->
+<h2><a name="simplecode">A simple and hackable code base</a></h2>
+<!--=======================================================================-->
+
+<p>Our goal is to make it possible for anyone with a basic understanding
+of compilers and working knowledge of the C/C++/ObjC languages to understand and
+extend the clang source base.  A large part of this falls out of our decision to
+make the AST mirror the languages as closely as possible: you have your friendly
+if statement, for statement, parenthesis expression, structs, unions, etc, all
+represented in a simple and explicit way.</p>
+
+<p>In addition to a simple design, we work to make the source base approachable
+by commenting it well, including citations of the language standards where
+appropriate, and designing the code for simplicity.  Beyond that, clang offers
+a set of AST dumpers, printers, and visualizers that make it easy to put code in
+and see how it is represented.</p>
+
 <!--=======================================================================-->
 <h2><a name="unifiedparser">A single unified parser for C, Objective C, C++,
 and Objective C++</a></h2>
@@ -209,22 +247,6 @@ clang in "strict" mode if you desire.</p>
 <p>We also intend to support "dialects" of these languages, such as C89, K&amp;R
 C, C++'03, Objective-C 2, etc.</p>
 
-<!--=======================================================================-->
-<h2><a name="gcccompat">GCC Compatibility</a></h2>
-<!--=======================================================================-->
-
-<p>GCC is currently the defacto-standard open source compiler today, and it
-routinely compiles a huge volume of code.  GCC supports a huge number of
-extensions and features (many of which are undocumented) and a lot of 
-code and header files depend on these features in order to build.</p>
-
-<p>While it would be nice to be able to ignore these extensions and focus on
-implementing the language standards to the letter, pragmatics force us to
-support the GCC extensions that see the most use.  As mentioned above, all
-extensions are explicitly recognized as such and marked with extension
-diagnostics, which can be mapped to warnings, errors, or just ignored.
-</p>
-
 
 <!--=======================================================================-->
 <h2><a name="libraryarch">Library based architecture</a></h2>