EricWF added a comment. OK, As I see it, we have two choices:
(1) Stash the expressions in Sema and import them like In https://reviews.llvm.org/D45476#1088047, @rjmccall wrote: > > Ah. If you want to be able to find this thing without a Sema around in order > to > handle deserialized expressions by just caching things in the ASTContext, > yes, > I agree that it would be difficult to build a `CXXConstructExpr` correctly. > I don't > fully understand the goal of avoiding serialization here, though. Perhaps I don't fully understand the goal of avoiding serialization either. >>> STLs *frequently* make use of default arguments on copy constructors (for >>> allocators). I agree that it’s unlikely that that would happen here, but >>> that’s precisely because it’s unlikely that this type would ever be >>> non-trivial. >> >> A couple of points. First, when I say copy constructor, I mean the special >> member, which >> cannot have default arguments, > > I'm sorry, but this is just not true. The formation rules for a copy > constructor are laid > out in [class.copy]p2, and they explicitly allow default arguments. Don't apologize because I'm wrong :-P. Thanks for the correction. >> Second, in the synopsis for the STL types, no constructors are declared. >> Although I don't >> think the standard spells it out anywhere, I believe this forbids the types >> from having user >> defined constructors (though perhaps not user-declared explicitly defaulted >> constructors. >> For example adding a user defined destructor would be non-conforming since >> it makes >> the types non-literal). > > That would certainly be helpful, but I don't think it's true; in general the > standard describes > what things are guaranteed to work with library types, but it doesn't > generally constrain > the existence of other operations. I think this is somewhat of a moot point, but I think the constraint is in `[member.functions]p2`: > For a non-virtual member function described in the C++ standard library, an > implementation may declare > a different set of member function signatures, provided that any call to the > member function that would > select an overload from the set of declarations described in this document > behaves as if that overload were selected. My argument is that because the class synopsis for the comparison category types doesn't describe or declare the copy constructor, so the implementation *isn't* free to declare it differently. https://reviews.llvm.org/D45476 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
