
<html><body><div>Hello everybody. This is my other proposal for the Google Summer of Code.</div><div>Since the student application deadline is very near, I've already submitted it</div><div>(and the other one about lambdas) to melange.</div><div>Comments and suggestions are really appreciated.</div><div><br></div><div>--</div><div><div>Title: Improving Clang's AST source-fidelity</div><div><br></div><div>1. Introduction:</div><div>Among the many strengths of clang, a most noticeable one is the excellent</div><div>support for client applications different from traditional compilers.</div><div>When compared to other systems, clang behaves spectacularly</div><div>better as far as source-code fidelity is concerned and is going to become</div><div>the reference choice for source-code based applications such as refactoring</div><div>tools, pretty printers and beautifiers, coding-style checkers, etc.</div><div><br></div><div>Most of this is a direct result of the accuracy with which the syntactic</div><div>structure of the parsed sources is represented in the clang AST:</div><div>different syntactic construct, even though semantically equivalent,</div><div>are provided with a precise AST representation that almost allows for</div><div>a faithful reconstruction of the original sources. Besides this, the AST</div><div>nodes encode accurate source location information to be used, e.g.,</div><div>when issuing diagnostic messages.</div><div><br></div><div>Even though clang does an excellent job, its AST representation</div><div>is not yet as accurate as it should be (i.e., not perfect).</div><div>Here is a list of current issues that can affect the precision of</div><div>source-code based applications using clang as front-end. This list of</div><div>issues has been obtained in strict cooperation with Roberto Bagnara,</div><div>Abramo Bagnara and Enea Zaffanella, who actively work with clang on</div><div>source-based applications and would be very happy to mentor this idea.</div><div><br></div><div>2. Issues:</div><div>*) Coherent encoding of expressions occurring in initializers.</div><div><br></div><div>The AST representation adopted by clang, besides encoding the syntactic</div><div>constructs explicitly occurring in the source code, also represents</div><div>those semantic constructs that are only implicitly occurring.</div><div>The classical examples are those of implicit type casts, default argument</div><div>expressions in C++ function calls, implicit declarations of special</div><div>member functions in C++ classes, etc. That is, the syntactic structures</div><div>get appropriately "dressed" by semantic info so that, for instance, type</div><div>information is always accurate.</div><div><br></div><div>For the special case of initialization lists, a somewhat different</div><div>approach is taken: clang makes a strong distinction between the syntactic</div><div>and the semantic forms of the initializer list. Even though the syntactic</div><div>form appropriately represents those initializer expressions that were</div><div>present in the source code, these may or may not be "dressed" with the</div><div>semantic info. On the other hand, the initializers in the semantic form</div><div>are always appropriately dressed, but here we typically see initializers</div><div>that were not actually present in the original sources.</div><div>The issue is discussed in the following thread:</div><div><br></div><div>http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-January/013037.html</div><div><br></div><div>We propose two changes to the handling of initializer lists.</div><div><br></div><div>The first change (which is of interest for source-code based applications)</div><div>is to modify the syntactic form of init list by requiring that all</div><div>expressions occurring in it are properly "dressed" by semantic info:</div><div>this will enhance the coherence of the AST representation for the targeted</div><div>applications.</div><div><br></div><div>The second change is an optimization of the representation of the</div><div>semantic form of initializer lists so as to increase node sharing and</div><div>hence greatly improve the memory footprint in special cases (again, see</div><div>http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-January/013037.html).</div><div>Besides improving AST node sharing, the idea is to also allow for</div><div>range designators inside the semantic form of init lists.</div><div>An example of code that currently behaves badly is the following:</div><div><br></div><div>int a[1000000] = { [0] = 1, [999999] = 1 };</div><div><br></div><div>---</div><div>*) Completing work on attributed types.</div><div><br></div><div>Currently, clang is sub-optimal when handling the following kinds</div><div>of declarations:</div><div><br></div><div>typedef __attribute__((mode(byte))) int small; // attribute disappears</div><div>small s1;</div><div>int __attribute__((mode(byte))) s2; // attribute is ignored</div><div><br></div><div>In the first case, the attribute is "consumed" during parsing, producing</div><div>a typedef referring to the semantic type 'signed char', with no indication</div><div>that, on the syntactic side, an attribute was used.</div><div>In the second case, the attribute is just ignored.</div><div><br></div><div>Recently, John McCall added new AST node AttributedType in the Type</div><div>hierarchy, in order to correctly model situations such as those above.</div><div><br></div><div>http://llvm.org/viewvc/llvm-project?view=rev&revision=122942</div><div><br></div><div>This new AST node is not yet integrated into the Parse/Sema routines.</div><div><br></div><div>---</div><div>*) AST representation for explicit instantiation of templates.</div><div><br></div><div>clang does not differentiate between the (syntactic) AST nodes declaring</div><div>an explicit instantiation of a template and the (semantic) instantiation</div><div>of the template. This can be observed by dumping the AST for the following</div><div>example:</div><div><br></div><div>template <typename T> struct s { };</div><div>extern template class s<double>;</div><div>extern template class s<int>;</div><div>extern template class s<int>;</div><div><br></div><div>obtaining something like:</div><div><br></div><div>template <typename T> struct s {};</div><div>struct s {};</div><div>struct s {};</div><div>class s;</div><div><br></div><div>Apart from minor pretty printing issues (such as the lack of the</div><div>"extern template" keywords and the lack of template argument lists),</div><div>we can see that the first instantiations for s<double> and s<int></div><div>are provided with a class body, because they reuse the semantic</div><div>instantiation node. This also has the side effect, for instance,</div><div>of printing "struct" instead of "class" as the tag keyword.</div><div>Compare this with the last declaration, which is a re-declaration of s<int></div><div>and is therefore provided with a new, syntactic node (in this case, the AST</div><div>structure is fine, we only need to improve the pretty printer).</div><div><br></div><div>---</div><div>*) Friend declarations</div><div><br></div><div>One of the problems with friend declarations, maybe also related to the</div><div>issue above, occurs when a template function that was declared to be a</div><div>friend of a class gets later instantiated, as in the following code:</div><div><br></div><div>template <class T></div><div>int foo() { return 0; }</div><div><br></div><div>class S {</div><div>friend int foo<S>();</div><div>};</div><div><br></div><div>void f() {</div><div>foo<S>();</div><div>}</div><div><br></div><div>The instantiation of foo inside f() causes the instantiation of the very</div><div>same function declaration that is referred by the friend declaration</div><div>in class S. Hence, the friend declaration becomes a definition,</div><div>causing troubles to source-based code tools.</div><div>Rather, the instantiation should result in the production of a new,</div><div>non-syntactic function declaration (i.e., a re-declaration of the</div><div>function declared as friend).</div><div><br></div><div>Another issue with friends has to do with so-called FriendTemplateDecl</div><div>AST nodes. According to current documentation, this AST node is never</div><div>produced by Parse/Sema:</div><div><br></div><div>01929 /// template <typename T> class A {</div><div>01930 /// friend class MyVector<T>; // not a friend template</div><div>01931 /// template <typename U> friend class B; // not a friend template</div><div>01932 /// template <typename U> friend class Foo<T>::Nested; // friend template</div><div>01933 /// };</div><div>01934 /// NOTE: This class is not currently in use. All of the above</div><div>01935 /// will yield a FriendDecl, not a FriendTemplateDecl.</div><div><br></div><div>---</div><div>*) Missing TypeSourceInfo for exception specifiers in FunctionProtoTypeLoc.</div><div><br></div><div>As an example, the AST representation for the exception specifier</div><div>in the following function declaration</div><div><br></div><div>void foo() throw(int (*)[2+1]);</div><div><br></div><div>is mapped into the semantic type where the array size is computed:</div><div><br></div><div>void foo() throw(int (*)[3]);</div><div><br></div><div>---</div><div>*) Missing flag for the presence of (optional) 'template' keywords</div><div>in nested name specifiers (NestedNameSpecifierLoc).</div><div><br></div><div>When parsing the following chunk of code</div><div><br></div><div>namespace BAR {</div><div><br></div><div>template <class U> static int foo();</div><div><br></div><div>template <typename T></div><div>void f() {</div><div>int (*g)();</div><div>g = &BAR::template foo<int>;</div><div>g = &BAR::template foo<T>;</div><div>}</div><div><br></div><div>} // namespace BAR</div><div><br></div><div>we obtain an AST representation with no info about the presence/absence</div><div>of the 'template' keyword.</div><div><br></div><div>---------</div><div>3. Why I'm interested in this project:</div><div>My main academic interest area is in the development of compilers, and for this reason</div><div>I've followed and used the LLVM and Clang project for the last two years.</div><div>Since I plan to graduate this year, the GSoC timeline fits quite well in my plans and</div><div>I would like this project to be my undergraduate thesis work.</div><div>This specific project has been proposed to me by Prof. Roberto Bagnara, from</div><div>University of Parma, which is very interested in this project and would be my</div><div>thesis co-relator.</div><div><br></div><div>4. How the project will be useful for LLVM:</div><div>Clang's AST code-fidelity is crucial for applications based on source code manipulation.</div><div>Having the most coherent and precise AST as possible is very important to reach Clang's</div><div>design goals.</div><div><br></div><div>5. Prior knowledge in compilers and LLVM:</div><div>As I said, in my academic life I've been interested primarily in compilers</div><div>implementation and design. For this reason, I'm following the Compilers course</div><div>at the University as part of my undergraduate degree in CS, and I've been interested</div><div>in LLVM and Clang projects for the last two years.</div><div>I've used the LLVM backend for a small personal project last year, and I've sent a couple</div><div>of trivial patches to Clang in 2009.</div><div><br></div><div>6. Academic, Industry and other experiences:</div><div>I'm an undergraduate student of the Computer Science course at the University of Udine, Italy</div><div>(http://www.uniud.it)</div><div><br></div><div>I've worked a lot with C++ in the last five years, including the development of two complex custom</div><div>C++ software systems for a quite big local industry, regarding industrial production and product</div><div>testing automation.</div><div><br></div><div>In 2009, I've successfully applied to the Google Summer of Code for the KDE project, implementing</div><div>KAuth, the authentication and authorization framework used by KDE desktops applications.</div><div><br></div><div>6. Contact information</div><div>e-mail: nicola.gigante@gmail.com</div><div>IRC nickname: gigabytes at FreeNode and OFTC</div><div>personal blog: http://www.gigabytes.it (In italian, sorry)</div></div><div><br></div><div>--</div><div><br></div><div>Bye,</div><div>Nicola</div><div><br></div></body></html>