The bit-fields of Type have enough space for the member
unsigned NumArgs of SubstTemplateTypeParmPackType.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/clang/AST/Type.h | ||
---|---|---|
1634 ↗ | (On Diff #160603) | I would love it if we commented what a reasonable number for this is. Additionally, we should probably make it 64 - NumTypeBits or something, to ensure that if NumTypeBits gets too large that we don't blow 64 bits here as well as communicate that it isn't necessary to keep this 32 bits. |
include/clang/AST/Type.h | ||
---|---|---|
1634 ↗ | (On Diff #160603) | The reason I did not do something like this is that If NumTypeBits gets too large then this will be detected by the Also I do not think that doing Given how many things will not work when NumTypeBits > 32 |
include/clang/AST/Type.h | ||
---|---|---|
1634 ↗ | (On Diff #160603) | My biggest fear here is basically that a future programmer coming in is going to figure that NumArgs REQUIRES 32 bits and try to start the discussion as to whether we can blow this bitfields up. A comment saying most of what you said above, plus a "This corresponds to implimits <whatever>, so it needs to support at least <num-ever>. |
The thing is that I have no idea what is the minimum number
of bits required. It was originally an unsigned but I suspect that
32 bits are not needed. Looking at [implimits] I see
Template arguments in a template declaration [1 024]. Recursively nested template instantiations, including substitution during template argument deduc- tion (17.8.2) [1 024].
But 1024 seems to be too small and easily exceeded by a doing a bit
of template meta-programming.
I suspect a minor rephrase of this comment would be more than sufficient for me:
"This field corresponds to the number of template arguments, which is expected to be at least 1024 according to [implimits]. However, as this limit is somewhat easy to hit with template metaprogramming we'd prefer to keep it as large as possible. At the moment it has been left as a non-bitfield since this type safely fits in 64 bits as an unsigned, so there is no reason to introduce the performance impact of a bitfield."
I'd suspect you/someone will bikeshed that, but I think it gets the point across that I want to make sure is there.
This comment seems fine. I will also add a similar comment to
TemplateSpecializationTypeBitfields, DependentTemplateSpecializationTypeBitfields
and PackExpansionTypeBitfields since they all 3 have a similar unsigned.
Sorry about the long discussion on the comment... These bitfields are just hell on the next guy through if he doesn't have the context/knowledge of what are appropriate sizes.