[cfe-dev] Serialization bug

[Ted Kremenek]

On Apr 20, 2008, at 7:22 PM, Zhongxing Xu wrote:

> The assertion fails because the DeclContext * field of i becomes 0x0  
> after deserialization.
>
> I am investigating the problem. What is the difference between InRec  
> and OutRec methods in serialization?

It's a low-level thing having to do with the bitcode file's use of  
"records".  Basically the bitcode file consists of a set of records,  
similar to XML, with special records (called "blocks") being allowed  
to contain other records in a tree-like structure.

InRec serializes out data that is basically guaranteed to remain in  
the same record.  OutRec serializes out data that is known to end the  
current record and create new ones.  Because each record adds extra  
metadata to the bitcode file, keeping things packed as much as  
possible in one record (as we do in InRec) saves space on disk.  It's  
purely an optimization thing.  For example, OutRec may call  
EmitOwnedPtr, which basically ends the current record with a  
persistent pointer ID for the next object being serialized out and a  
new record contains the data for the other object.

Here is an example:

1) EmitInt
2) EmitInt
3) EmitOwnedPtr(X)
4) EmitInt

(1) and (2) just write out the bits for an integer; EmitInt doesn't  
terminate the current record, but just adds more data to it.   
EmitOwnedPtr then writes out a single integer (in the current record)  
to represent the persistent pointer ID, then starts a new record which  
contains the data of X, then ends that record.  Then (4) is written  
out, this time in a new record (since no record is active).  This  
leads to 3 records (assuming X is contained in one record).  A more  
optimal encoding is to move (4) before (3), causing us to have 2  
records.

So... EmitInRec and EmitOutRec are just methods where we have  
collected the data that will be written in the current record  
(EmitInRec) and data that will result in the creation of other records  
(EmitOutRec).  EmitOutRec should be called after EmitInRec.

One last thing: the serialization support is incomplete.  I stopped  
fully implementing it when I got to handling EnumDecls and  
RecordDecls, since we then (and still don't) have a clear ownership  
model for all of these decls (which the serialization mechanism  
absolutely depends on).  I plan on completing it one day, but it  
wasn't pressing at the time (and I knew the ASTs would evolve and some  
of the ownership issues would get cleaned up).