Space for storing the constraint-expression of the requires-clause associated with a TemplateParameterList is arranged by taking a bit out of the NumParams field for the purpose of determining whether there is a requires-clause or not, and by adding to the trailing objects tied to the TemplateParameterList. An accessor is provided.
An appropriate argument is supplied to TemplateParameterList::Create at the various call sites.
Serialization changes will addressed as the Concepts implementation becomes more solid.
Drive-by fix:
This change also replaces the custom FixedSizeTemplateParameterListStorage implementation with one that follows the interface provided by llvm::TrailingObjects.
Yuk - this entire guy (FizedSizeTemplateParameterListStorage) seems quite fragile (dependent on object layout) - are the gains (in the single use below during auto-type deduction) in preformance really worth the introduction of this fragility/ugliness?
Unless there is a clear win from this strategy, I think i'd favor (perhaps in a later patch) - either just removing this structure and using TPL for the use-case in auto-type below, or using placement new and creating the stack TPL on a stack unsigned char array?
Thoughts?