<div dir="ltr">I agree with Ted that we should separate syntax thing from semantics thing in the AST.<br><br>struct s;<br>struct s a;<br>struct s { int d; } x;<br><br>These 'struct s' have different meanings: type declaration, type specifier, type definition.<br>
But syntactically they are all RecordDecl.<br><br>Having Type owns Decls introduces confusion.<br><br>-Zhongxing Xu<br><br><div class="gmail_quote">2008/9/12 Argiris Kirtzidis <span dir="ltr"><<a href="mailto:akyrtzi@gmail.com">akyrtzi@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">Ted Kremenek wrote:<br>
><br>
> On Sep 11, 2008, at 5:53 AM, Argiris Kirtzidis wrote:<br>
><br>
>> Ted Kremenek wrote:<br>
>>> Note that this completely resolves the ownership issues with anonymous<br>
>>> structs and similar constructs.  It also means that Types no longer<br>
>>> own Decls (a good thing).<br>
>>><br>
>><br>
>> There's an ownership issue that is not mentioned:<br>
>><br>
>> x = sizeof( struct { int z; } );   // who owns this RecordDecl ?<br>
>><br>
>> This may indicate that RecordDecls are fundamentally part of Type and<br>
>> should be owned by a Type.<br>
><br>
> Hi Argiris,<br>
><br>
> This is an excellent point.  There are a couple reasons why I strongly<br>
> don't believe that types should ever own elements of the AST.<br>
><br>
> From an aesthetic perspective, declarations represent program syntax,<br>
> while types are part of the program semantics.  I don't believe our<br>
> data structures representing semantics should own the data structures<br>
> that represent program syntax.  They can refer to each other, but<br>
> there isn't an ownership relationship here.  Conceptually it just<br>
> doesn't make much sense, and I believe that one of the goals of the<br>
> ASTs is that they should be conceptually clean as possible.  This<br>
> allows clients of the ASTs to understand their invariants much more<br>
> easily.  This was actually one of the prime motivation of the<br>
> DeclGroup idea that Daniel and I put forth.  Beyond cleaning up some<br>
> ownership issues, DeclGroups really do capture more elements of C's<br>
> actually syntax.<br>
><br>
> Another reason that having types own Decls is that it really makes<br>
> things much more difficult for clients that wish to modify the AST.<br>
> When is a Decl owned by a type?  With the idea you propose, a DeclStmt<br>
> might own a TypeDecl if it isn't a RecordDecl, but in the case of a<br>
> RecordType the type would own it.  There is also the problem that we<br>
> now have multiple RecordDecls for a given RecordType.  Does the<br>
> RecordType own all of those RecordDecls?  This actually makes<br>
> manipulation of the AST really tricky and error prone.<br>
<br>
</div></div>To be more clear, the idea is that TypeDecls are owned by Types, and<br>
only one RecordDecl would be created.<br>
Can clients modify the AST without involving Types ? Assuming one<br>
RecordDecl in the AST is replaced with another, what about the<br>
RecordType the refers to it ?<br>
My point is that if the DeclGroup owns the RecordDecl, the Type will<br>
still need to be updated. If the Type owns the the RecordDecl you may<br>
only need to update the Type.<br>
<br>
You also mention that:<br>
<div class="Ih2E3d"><br>
> - Source-Fidelity: We capture much more of the source information in<br>
>   the ASTs.  This is great for refactoring clients.<br>
<br>
</div>The way I see it, DeclGroups mostly solve ownership issues, it's not a<br>
"real" solution for refactoring clients. These clients would want all<br>
type references too, not just forward declarations and definitions.<br>
The only way to support refactoring clients seems to be the proposal by<br>
Chris here:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002614.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002614.html</a><br>
which is a kind of "Type AST" thing, so complicating the type system may<br>
be inevitable. TypeDecls may be part of that "Type AST".<br>
<font color="#888888"><br>
-Argiris<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
><br>
> From my perspective, Decls just represent syntax, and if our current<br>
> ASTs cannot adequately capture such elements of the syntax then they<br>
> need to be augmented.  In the case of sizeof(type), it seems to me<br>
> that a reasonable solution would be to have SizeOfAlignOfTypeExpr<br>
> refer to a variant instead of a QualType.  In the common case the<br>
> variant would just refer to a QualType, and in the other case it would<br>
> refer to both a QualType and a TypeDecl (in which case it owns the<br>
> TypeDecl).  Using either smart pointers or subclassing of<br>
> SizeOfAlignOfTypeExpr, it seems that the storage of such extra<br>
> information could readily be incorporated into the AST.<br>
> getArgumentType() could then be made virtual (if necessary) to query<br>
> the appropriate field.<br>
><br>
> The nice thing about this solution is that it isolates the ugliness of<br>
> C's grammar for this particular problem into a few bits of code in the<br>
> AST, rather than complicating the representation of the C type system<br>
> or introducing hard to reason about ownership issues between Types and<br>
> Decls.  Naturally the parser would need to be augmented to reason<br>
> about variants as well; i.e., in the case of sizeof(type), the logic<br>
> in the parser that returns the QualType for "type" actually may return<br>
> a "type" or a "decl".  This seems fine to me; we're already passing<br>
> variants around in the parser.  Another thing that's nice about this<br>
> solution is that IMHO it is conceptually clean; the fact the sizeof<br>
> can refer to a type or a decl is just a consequence of C's grammar<br>
> that is represented faithfully in the AST itself; clients that care<br>
> about whether or not sizeof(type) actually refers to a declaration<br>
> will need to be able to distinguish between these cases, and other<br>
> clients that just want the type that sizeof(type) refers to won't have<br>
> to care at all.<br>
><br>
> There will likely be other corner cases like sizeof(type) that we will<br>
> need to handle, but these all seem to me to be issues of syntax that<br>
> require enhancements to the AST themselves.  Having the RecordTypes<br>
> own RecordDecls really just seems like a short-term solution that<br>
> muddles the conceptual cleanliness of the ASTs and introduces<br>
> artificial ownership relationships between types and decls that we<br>
> would only think about introducing in order to solve gross corner<br>
> cases like these.  It just doesn't feel like the right solution to me.<br>
><br>
> Ted<br>
><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>