<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">All good points...<div><br></div><div>Sometimes it's useful to consult the spec to help weigh various design points.</div><div><br></div><div>That said, C99 6.7.2.3p3 says...</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">All declarations of structure, union, or enumerated types that have the same scope and<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">use the same tag declare the same type. The type is incomplete<span style="font: 9.0px Times">109)</span><span style="font: 12.0px Helvetica"> </span>until the closing brace<span style="font: 12.0px Helvetica"> </span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Times; ">of the list deļ¬ning the content, and complete thereafter.<span style="font: 12.0px Helvetica"> </span></div><div><br></div><div><div>Since both x and y have the same type, I don't see any compelling reason to alter the type system.</div><div><br></div><div>struct S{} x;<br>struct S y;<br><br></div><div>From my perspective, we need to have a compelling reason to fold this into the type system.</div><div><br></div><div>If not, I think the DeclGroup solution will work fine (and appears simpler).</div><div><br></div><div>snaroff</div><div><br></div><div>On Sep 12, 2008, at 1:07 PM, Daniel Dunbar wrote:</div></div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Argiris,<br><br>To start, let me just say that I think there are a few different<br>things going on in this<br>thread, and its a bit hard to discuss any of them (especially over<br>email), so it would<br>be good to break them up into separate problems where possible.<br><br>A few comments:<br><br>First, I am not clear exactly what problem you are solving here. Are<br>you proposing<br>this as an alternative to DeclGroups? And what are the problems you<br>are addressing?<br><br>Second, it would be nice to conceptually separate the solutions to the multiple<br>RecordDecl issue and the DeclGroup proposal. They overlap to some extent, it<br>is true, but I think they are separate issues and should be solved as such.<br><br>Third, in my mind encoding any part of the AST using Types is not a<br>good design. Having<br>them be related to one another is ok, but having things embedded in<br>the Type should<br>be an implementation detail, not something forced by the Parser or<br>even Sema. I am<br>especially wary of a design which has Types owning part of the AST.<br><br>Fourth, the main idea of DeclGroup was simply to capture the<br>"declarator-list" part of the<br>C grammar. I think this is what Ted meant about begin more faithful to<br>the grammer.<br><br>Fifth, if the problem you are solving is the ambiguity in whether a<br>structure use is a<br>definition or a declaration, then I agree that this should be solved,<br>but I do not think<br>it should be solved by introducing new types. I argued with Ted that<br>we should introduce<br>additional Decls to capture the syntactic (and semantic) distinction between:<br> a. Introducing a new structure definition (which may be incomplete)<br>into scope.<br> b. Referring to a previously declared structure.<br>However, in the end I decided that the introduction of this could be<br>delayed until after<br>the other changes to RecordDecl and the introduction of DeclGroup.<br>Those are more<br>important for solving ownership issues, which are in turn blocking<br>serialization.<br><br>More concretely, I believe there are some issues with your proposal:<br><br>(1) What is the representation of<br> typedef struct x { ... } a, b, d, e ..., z;<br>Representing this, and capturing ownership, was really the key part of<br>DeclGroup.<br><br>(2) Re:<br><blockquote type="cite">'y' gets a new RecordTypeDef type, which owns the RecordDecl. We avoid<br></blockquote><blockquote type="cite">the overhead of using multiple DeclGroups for the parameters.<br></blockquote>This is a bit misleading, for all the common important cases DeclGroup can be<br>encoded in a way that doesn't have any additional memory overhead (and the<br>performance overhead of access through a smart pointer should be negligible).<br>Actually by my calculations we were going to save memory using DeclGroup.<br><br>I'd like to make sure we are all on the same page about what problems we<br>are solving (and break them down as much as possible) before going into to<br>many specifics about the solution.<br><br> - Daniel<br><br>On Fri, Sep 12, 2008 at 7:38 AM, Argiris Kirtzidis <<a href="mailto:akyrtzi@gmail.com">akyrtzi@gmail.com</a>> wrote:<br><blockquote type="cite">Here's a proposal, collecting the arguments into one post:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Modifying Type to better represent 'type-specifier' in the syntax:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">As Ted mentioned, there's a problem on how we represent struct<br></blockquote><blockquote type="cite">declarations inside type-specifiers:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Example:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">void f() {<br></blockquote><blockquote type="cite"> typedef struct x { int y; } foo; // #1<br></blockquote><blockquote type="cite">}<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Syntactically this is what we have for #1:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">typedef struct x { int y; } foo; -> 'typedef' type-specifier 'foo' ';'<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">and we treat it as: 'typedef' ['struct x' reference] 'foo' ';'<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">There's no information that 'struct x' is defined inside the typedef<br></blockquote><blockquote type="cite">declaration. Also it's not clear who owns the RecordDecl.<br></blockquote><blockquote type="cite">I suggest that we treat it as:<br></blockquote><blockquote type="cite">'typedef' ['struct x' definition] 'foo' ';'<br></blockquote><blockquote type="cite">resulting in a RecordTypeDef Type for the TypedefDecl. This gives us the<br></blockquote><blockquote type="cite">information that we have a 'struct x' definition inside the<br></blockquote><blockquote type="cite">type-specifier of #1.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What about ownership of RecordDecl ?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">There will be a 1-to-1 mapping between RecordTypes and RecordDecls,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">struct x; -> A new incomplete RecordDecl is created here.<br></blockquote><blockquote type="cite">struct x {}; -> The previously created RecordDecl is fully defined.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">and RecordType will own it. What is the advantage of that ? Ownership<br></blockquote><blockquote type="cite">matters when a client wants to modify the AST. When the client says "I<br></blockquote><blockquote type="cite">want to replace this RecordDecl with another one" it usually means<br></blockquote><blockquote type="cite">"Everywhere in this translation unit, if a Type references this<br></blockquote><blockquote type="cite">RecordDecl, I want it to reference this RecordDecl instead.". The client<br></blockquote><blockquote type="cite">will accomplish this by replacing the one RecordDecl owned by the<br></blockquote><blockquote type="cite">RecordType with another one.<br></blockquote><blockquote type="cite">The alternative would be replacing all the RecordDecls (forward decls<br></blockquote><blockquote type="cite">and defs) present, *and* replacing the RecordDecl that the RecordType<br></blockquote><blockquote type="cite">references.<br></blockquote><blockquote type="cite">Also, by having only one RecordDecl we avoid the overhead of creating<br></blockquote><blockquote type="cite">multiple RecordDecls.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If the two constructs above are not RecordDecls owned by the<br></blockquote><blockquote type="cite">translation unit, how are they represented in the AST ?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Syntactically they look like this:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">struct x; -> type-specifier ';'<br></blockquote><blockquote type="cite">struct x {}; -> type-specifier ';'<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">similar to this, which we currently ignore:<br></blockquote><blockquote type="cite">int; -> type-specifier ';'<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I suggest representing them with a kind of 'TypeSpecDecl' declaration<br></blockquote><blockquote type="cite">node. This will allow us to also capture "int;" in the AST:<br></blockquote><blockquote type="cite">int; -> TypeSpecDecl with type 'int'<br></blockquote><blockquote type="cite">struct x {}; -> TypeSpecDecl with type RecordTypeDef defining<br></blockquote><blockquote type="cite">RecordDecl 'x'<br></blockquote><blockquote type="cite">struct x; -> TypeSpecDecl with type RecordTypeRef, referencing<br></blockquote><blockquote type="cite">RecordDecl 'x'<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Other occurences of type-specifier are represented in a consistent way:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">int foo(int x, struct { int a; } y);<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">'y' gets a new RecordTypeDef type, which owns the RecordDecl. We avoid<br></blockquote><blockquote type="cite">the overhead of using multiple DeclGroups for the parameters.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">sizeof (struct { int x;}) -> 'sizeof' '(' type-specifier ')' -> A new<br></blockquote><blockquote type="cite">RecordTypeDef type passed to sizeof.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This approach of handling records will also apply to enums, basically<br></blockquote><blockquote type="cite">it's about handling the tag declarations appearing inside<br></blockquote><blockquote type="cite">type-specifiers. Consequently, this approach does not apply to typedefs:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">typedef int x; -> syntactically (and semantically) 'typedef'<br></blockquote><blockquote type="cite">type-specifier 'x' ';' -> a TypedefDecl 'x'<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Typedefs don't have the complications of tag types, they will be handled<br></blockquote><blockquote type="cite">the same way as now.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Any thoughts?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-Argiris<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">cfe-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br></blockquote><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br></blockquote><blockquote type="cite"><br></blockquote>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></div></blockquote></div><br></div></body></html>