<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 16, 2008, at 6:27 PM, Argiris Kirtzidis wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><blockquote type="cite">Consider:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> extern int h(int* x) __attribute__((nonnull)); extern int h(int *x);<br></blockquote><blockquote type="cite"> extern int h(int* x) __attribute__((noreturn));<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">This code is completely valid. In the ASTs we create three FunctionDecls, the first having the attribute "nonnull" attached to it (and object of type NonNullAttr) and the third having the attribute "noreturn" attached to it (an object of type NoReturnAttr).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Suppose I had a client (e.g., code generation, static analysis) that wanted to know all the attributes attached to a given function. How would I go about doing this?<br></blockquote><br>If I'm not mistaken, the latest declaration is supposed to "merge" the information from all previous declarations through Sema::MergeFunctionDecl, and that includes attributes.</span></blockquote><div><br></div><div>To my chagrin I was not aware of this. Thanks for pointing it out!</div><div><br></div><div>The problem I have with this approach is that it relies on the ASTs being constructed in a very special way. Sema of course has to do the right thing, but what about other entities that create or modify ASTs? Put another way, it is not clear to me, from looking at the ASTs, that the invariant you mentioned is in place. It's just something that is silently there because of the way Sema does things.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><br>The client would only need to query information from the latest declaration.<br><br>FYI, there was a long-winded discussion on what is a good way to combine the information from all FunctionDecls and use the same FunctionDecl pointer throughout the AST, here:<br><a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-April/001479.html">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-April/001479.html</a><br><a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-May/001608.html">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-May/001608.html</a><br><br></span></blockquote></div><div><br></div><div>My own feeling, and from reviewing the threads you mentioned and from looking over the recent discussions on this list, that reusing Decls (either by merging them, changing SourceLocations, etc.) just doesn't seem right. Gradually mutating the Decl objects as we construct the rest of the AST for a translation unit just seems messy, and makes modifying or creating AST nodes error prone. Reusing Decls to me makes it inherently harder to capture the way a user wrote the code. I'm willing to put this part of the argument, however, until we have actually gone and implemented some of TypeSpecifier and DeclGroup to see what we are left with.</div><div><br></div><div>To me declarations represent syntax, and should reference the thing they are declaring. RecordDecls already do this with RecordTypes (since there is a many-to-one mapping here), but we don't have a similar concept for variables and functions.</div></body></html>