[PATCH] TypeOfExpr serialization

This patch adds serialization support for TypeOfExpr. It assumes TypeOfExpr owns the Expr. Is this right?

serz.patch (1.95 KB)

This looks right to me!

On a separate issue, I'm mixed on having TypeOfExpr own the Expr (which I assume is the case right now). VLA types also own their size expressions, but I've never felt that Types should own expressions. This is a long-standing issue, however with the ASTs.

Yeah. Having types own decls causes failure of serialization/deserialization on this code:

struct s {
};

The struct is serialized twice: once by translation unit, the other by the type which owns it. When deserialized the second time, RegisterPtr() fails due to that the backpatch map already has final pointer.

Zhongxing Xu wrote:

    This looks right to me!

    On a separate issue, I'm mixed on having TypeOfExpr own the Expr
    (which I assume is the case right now). VLA types also own their
    size expressions, but I've never felt that Types should own
    expressions. This is a long-standing issue, however with the ASTs.

Yeah. Having types own decls causes failure of serialization/deserialization on this code:

struct s {
};

The struct is serialized twice: once by translation unit, the other by the type which owns it. When deserialized the second time, RegisterPtr() fails due to that the backpatch map already has final pointer.

If the Decl is owned twice, then it should also cause crashes on shutdown, due to double deletion. Why does the type own the decl anyway? Isn't the type produced by the ASTContext on request, from the decl? How can it possibly own it?

Of course, types owning expressions is different from types owning decls.

Sebastian

In current AST construction/deconstruction, the Decl is not owned by TagType. In this code:

typedef struct s{} s_t;

The RecordDecl for ‘struct s {}’ is leaked, because it’s not owned by anyone.

But in AST serialization, currently we do assume TagType own its Decl. That’s why the crash occurs.

Interesting. It doesn't bother me at all to have the types own their expressions, because the expressions are logically a part of the type and need to live as long as the type.

  - Doug