Probable problem in ElaboratedType AST representation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Probable problem in ElaboratedType AST representation

Abramo Bagnara

Analyzing the AST produced for this snippet:

struct g {
  struct h {
    struct v;
    h::v *y;       /* (1) */
    class h::v *z; /* (2) */
  };
};

I see that the syntactic info for (2) are lost, while they are not for (1).

In (1) the type for y is translated to PointerType -> QualifiedNameType
-> RecordType
In (2) the type for z is translated to ElaboratedType -> PointerType ->
RecordType

This mean that in (2) there are currently no containers to represent the
NestedNameSpecifier that in (1) we have inside QualifiedNameType.

The problem is shown also using -ast-dump -emit-ast:

struct g {
public:
    struct g;
    struct h {
    public:
        struct h;
        struct v;
        h::v *y;            /* (1) */
        class g::h::v *z;   /* (2) */
        inline h();
        inline h(struct g::h const &);
        inline struct g::h &operator=(struct g::h const &);
        inline void ~h();
    };
    inline g();
    inline g(struct g const &);
    inline struct g &operator=(struct g const &);
    inline void ~g();
};

While in (1) we have only the name specifiers present in the source, in
(2) we have always the full name specification.

I'd like to know if this problem is confirmed and if the design
intention is to have a QualifiedNameType also under ElaboratedType or to
encode the missing info in an other way.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Probable problem in ElaboratedType AST representation

John McCall
On Jan 6, 2010, at 2:40 PM, Abramo Bagnara wrote:
> I'd like to know if this problem is confirmed and if the design
> intention is to have a QualifiedNameType also under ElaboratedType or to
> encode the missing info in an other way.

This is a known problem.  It actually causes a bug because we don't look up the qualified type appropriately during template instantiation.  The eventual AST representation will probably be what you suggest, that the child type will be allowed to be a QualifiedNameType or (dependently) a TypenameType, and template instantiation will just have to treat these cases differently.

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev