I found this when reading the codes. I think it makes sense to reduce the space for TemplateParmPosition. It is hard to image the depth of template parameter is larger than 2^20 and the index is larger than 2^12. So I think the patch might be reasonable.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Changes LGTM, I also don't think we should hit these limits. Perhaps we should add some assertions to the ctor and the setter functions just to be sure though?
If we are going to do anything, it ought to be a diagnostic?
I can't imagine a scenario in which someone would hit these limits and have assertions enabled. But i agree with you that the limit themselves should not be hit.
On the other hand, why not use 16 for both?
Doing a diagnostic would mean finding all the places where we form a TemplateParmPosition and ensure we have enough source location information to issue the diagnostic. Given that we don't expect users to ever hit it, having the assertion gives a wee bit of coverage (godbolt exposes an assertions build, for example) but without as much implementation burden. That said, if it's easy enough to give diagnostics, that's a more user-friendly approach if we think anyone would hit that limit. (I suspect template instantiation depth would be hit before bumping up against these limits, though.)
I can't imagine a scenario in which someone would hit these limits and have assertions enabled. But i agree with you that the limit themselves should not be hit.
On the other hand, why not use 16 for both?
I think people instantiate to deeper template depths than they typically have for template parameters, so having a deeper depth made sense to me.
I think people instantiate to deeper template depths than they typically have for template parameters, so having a deeper depth made sense to me.
Hmm... the cases I can think of make me think this isn't necessarily true... It is very common to template-recurse on an integer-sequence of some sort, which would result in depth and position being roughly the same.
I note that 'recursive' depth is limited to 1024: https://godbolt.org/z/h9bEfsToT
Though I think there are other ways to get 'deeper' than that. So perhaps in any case we're just arranging deck chairs on a -post-error titanic :)
On the other hand, why not use 16 for both?
I am consistent with @aaron.ballman here.
clang/include/clang/AST/DeclTemplate.h | ||
---|---|---|
1155–1166 | I don't find standard way to generate the maximum value for bit fields.. So I choose to calculate it by hand. | |
1162–1163 | I find it is possible if ast-dump is going to dump from JSON files. |
clang/include/clang/AST/DeclTemplate.h | ||
---|---|---|
1155–1166 | Maybe we're able to drop the -1 here. But I feel it breaks the semantics. So I feel it is not good. |
Still LG to me, but please watch the build bots and issues list closely for any new template instantiation depth/position related issues over the next short while given that we're making a best guess at the bit widths here.
clang/include/clang/AST/DeclTemplate.h | ||
---|---|---|
1155–1166 | I don't insist. :-) |
Thanks! I looked at the build bots and the failure cases is about ompt. And I think it is unrelated to this patch though.
Just as constant as a macro, but without all the macro issues.