Athosvk added a comment.

In, @juliehockett wrote:

> If you take a look at the follow-on patch to this (D43341 
> <>), you'll see that that is where the pointer 
> is added in (since it is irrelevant to the mapper portion, as it cannot be 
> filled out until the information has been reduced). The back references to 
> children and whatnot are also added there.

Oops! I'll have a look!

In, @juliehockett wrote:

> The USRs are kept for serialization purposes -- given the modular nature of 
> the design, the goal is to be able to write out the bitstream and have it be 
> consumable with all necessary information. Since we can't write out pointers 
> (and it would be useless if we did, since they would change as soon as the 
> file was read in), we maintain the USRs to have a means of re-finding the 
> referenced declaration.

What I was referring to was the storing of a USR per reference. Of course, 
serializing pointers wouldn't work, but what I mean is that what we used as a 
USR was stored in what was pointed to, not in the reference that tells what we 
are pointing to. To be a little more concise, a RecordInfo has pointers to the 
FuntionInfo for its member functions. Upon serialization, the RecordInfo 
queries the USR of those functions. A function being referenced multiple times 
remains to only have the USR stored. If I understand correctly, you currently 
save the USR for time an InfoType references another InfoType.

Anyhow, don't pay too much attention to that comment, it's all meant as a minor 
thing. It sure is looking good so far!

cfe-commits mailing list

Reply via email to