[cfe-dev] [PATCH] PCH Support for C++ decls

Douglas Gregor dgregor at apple.com
Mon Mar 29 11:37:58 PDT 2010


On Mar 8, 2010, at 7:44 AM, Andrew Sutton wrote:

>> I've spent the morning addressing issues in the patch and had some questions, comments. I'm not sending up a new patch just yet, though.
> 
> I had planned to send this up on Saturday, but couldn't connect to the server in the morning so I worked on other stuff instead. Attached is a new version of C++/PCH Decl support. I think I've addressed all of your comments. I've also added support for
> 
> - unresolved value/type decls
> - friend type references
> - ctor member initializers
> - stubbed a function for friend template decls

It would be much easier to handle such additions as separate patches once the main patch has gone in. Big patches take much longer to review. We haven't quite dealt with all of the issues there yet.

Also, friends are in a state of flux, so it's not worth trying to (de-)serialize them now. Once the AST settles down and access control is turned on by default, it will make sense to implement PCH support with friends.

> There are 3 issues with this patch that I either don't like or are cause problems.
> 
> 1. I needed a way to attach the DefinitionData of a CXXRecordDecl that is not a definition to a previously defined record declaration via the PCH reader (hence the attachDefinition()) function in CXXRecordDecl. It basically addresses this problem:
> 
> class C { };
> class C; // DefinitionData not attached during reading
> 
> The DefinitionData isn't attached but the previous declaration is set correctly. IIRC, the same situation happens with injected class names.
> 
> I'm not thrilled with this solution. I think the best solution would be to make setPreviousDeclaration automatically share (forward?) DefinitionData. I just didn't want to open that can of worms in this patch.

Since you posted the original patch, a better solution has come up. When we start a definition of a CXXRecordDecl, we go back and fix up all of the DefinitionData pointers.

> 2. Anonymous namespaces within other namespaces appear to be incorrectly linked in semantic analysis but not PCH serialization. Of course, my interpretation of C++ semantics may also be wrong :) Let's say we have:
> 
> // Yes, there are two of  them
> namesapce N { namespace { class C; } } // 1
> namesapce N { namespace { class C; } } // 2
> N::C* p; // ERROR ambiguous lookup for C.
> 
> My understanding is that the anonymous namespace should be linked so that 1 and 2 refer to the same class. Is that right? I added a test to SemaCXX/namespaces.cpp to check.

Yes, good catch. I ended up fixing this as part of PR6341.

> 3. There seems to be a bug in the PCH reader when you explicitly initialize member variables of a base class. Let's say you have:
> 
> struct B : A {
>   B() : A(), x() { } // <- ASSERT
>   int x;
> };
> 
> The assertion occurs in the deserialization (ReadStmt) of the ImplicitValueInit expr for x(). Somehow, after visiting that stmt/expr, the Idx == Record.size() - 1. Curiously, if B has no base classes, this seems to work fine.
> 
> I'm not sure what the status of this patch is going to be since a) clang/llvm seems to be in a code freeze and b) this patch introduces an assertion. I have a lot of other things to take care of so I may not be able to address those issues in a timely manner.

Only the 2.7 branch of Clang/LLVM is in code freeze. The trunk is in its usual frenzy of activity.

Overall, this patch isn't quite ready to go in. I've attached an updated version of the patch, which brings your patch into line and fixes some of the issues. It cleans up the handling of DefinitionData (#1), eliminates the code for friend type references (which have changed, and may change yet again), and takes a step further toward getting conversion functions right. However, to get conversion functions 100% correct, the list of conversion functions needs to be loaded lazily: see the FIXME I added in PCHDeclReader::VisitCXXRecordDecl.

I think fixing conversion functions and the ctor-initializers are crucial for this patch to go in.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100329/c5cef5d7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pch-updated.patch
Type: application/octet-stream
Size: 77796 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100329/c5cef5d7/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100329/c5cef5d7/attachment-0001.html>


More information about the cfe-dev mailing list