[cfe-dev] Better type-specifier representation

[Daniel Dunbar]

Okay, I think I understand where you are coming from. And I agree
about everything except using the types to encode the type specifier. :)

If we want to explicitly represent the type specifier, what is wrong with
actually making this a separate node (not a Type and not a Decl). We can
probably present the abstraction that the AST has TypeSpecifier nodes
without actually creating them (by encoding in DeclGroup or other tricks).

This also gives a clear place to attach source range, makes clear what the
representation of sizeof(type) is (a SizeofAlignOfTypeExpr which points to
a TypeSpecifier which in turn points to the type), and should make ownership
clear.

I don't see any clear reason why, if we want this, we should embed it into
the type (which is fundamentally incorrect, a type specifier is not a type, many
things have different type specifiers but the same type).

 - Daniel

On Fri, Sep 12, 2008 at 3:11 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> Hi Daniel,
>
> Daniel Dunbar wrote:
>>
>> Fifth, if the problem you are solving is the ambiguity in whether a
>> structure use is a
>> definition or a declaration, then I agree that this should be solved,
>>
>
> Yes, this is the problem.
>
>> More concretely, I believe there are some issues with your proposal:
>>
>> (1) What is the representation of
>>  typedef struct x { ... } a, b, d, e ..., z;
>> Representing this, and capturing ownership, was really the key part of
>> DeclGroup.
>>
>
> A DeclGroup, of TypedefDecls, which have type RecordDefType, pointing at
> RecordDecl 'x'.
> The DeclGroup doesn't have to point and own the RecordDecl.
> The RecordDecl can be uniqued and be owned by the translation unit.
>
>> but I do not think
>> it should be solved by introducing new types. I argued with Ted that
>> we should introduce
>> additional Decls to capture the syntactic (and semantic) distinction
>> between:
>>   a. Introducing a new structure definition (which may be incomplete)
>> into scope.
>>   b. Referring to a previously declared structure.
>> However, in the end I decided that the introduction of this could be
>> delayed until after
>> the other changes to RecordDecl and the introduction of DeclGroup.
>> Those are more
>> important for solving ownership issues, which are in turn blocking
>> serialization
>
> This is what I'm suggesting against: over-complicating the AST by
> introducing various Decls or Exprs for providing information for something
> that is fundamentally part of a type-specifier.
>
> -We will introduce additional Decls for distinction between new type
> definition or reference in declarations (simpler option is not to introduce
> additional decls)
> -Use DeclGroup for function parameters (even if there's no overhead, using
> ParmVarDecl is the simpler option)
> -introduce some kind of decl or expression for the struct in "sizeof (struct
> {})" (simpler option is to use a Type, as we do now)
> -The same for casts "(struct{}) x"
> -in C++ use additional decl (or DeclGroup ?) for a condition declaration:
> "if (struct {}* x = 0) {}" (simpler option is to use a single VarDecl as
> now)
> -Something to distinguish C++ new: "new struct{}()"
>
> There must be other places where trying to distinguish between
> reference/definition is going to complicate things, basically anywhere that
> a type may be used, this is off the top of my head.
>
> All these cases can be handled uniformly and in a much simpler way by
> introducing the RecordDefType, and making the distinction based on the thing
> which actually carries the ambiguity (the type-specifier).
>
>
> -Argiris
>