Previously LambdaDefinitionData extended DefinitionData and either might have been used interchangably in a CXXRecordDecl's DefinitionData field.
However there are cases where LambdaDefinitionData ("LDD") aren't copied or moved completely, into this DefinitionData ("DD") field, as it has additional members of its own.
This patch:
- makes LDD a separate structure, no longer using DD as the base class, but otherwise kept the same so as to encapsulate lambda stuff properly
- stores lambda data within an Optional called LambdaData
- replaces IsLambda bit with bool isLambda() const, true IFF lambda data are present in that optional field
- as the formerly-subclass's LDD constructor set some members on DD, this is now done in a new method SetLambdaData; this sets those fields to values sensible for lambdas, and emplaces lambda data in the optional field
This solves one case where lambda data were not handled quite properly.
Note that this doesn't solve all lambda-handling in pcm's (clang modules) but is more of a refactoring pre-step.
Test Plan: ninja check-clang-modules
Hi @rsmith, thanks again for looking! This is the part that I was concerned about: that DD could be either a DefinitionData or LambdaDefinitionData reference; similar MergeDD. It didn't seem that move-assign was well-defined in the cases where they were mixed.
If their being different is completely unexpected, though, this whole thing could perhaps be an assertion that they are both lambda, or both not lambda. And an IsLambda field on the CXXRecordDecl` (or TTK_Lambda).
Alternatively, I could make the lambda data a pointer or std::unique_ptr<LambdaDefinitionData> inside DefinitionData (and maybe make the latter final), so as not to allocate much extra space in the non-lambda case.
Depends on whether a new tag type is not too much of a breaking change. Also, whether it's known at this point that this record is a lambda (and DD is already of the correct type).