[PATCH] D128113: Clang: fix AST representation of expanded template arguments.

Alexander Kornienko via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 24 08:17:47 PDT 2022


alexfh added a comment.

In D128113#3744353 <https://reviews.llvm.org/D128113#3744353>, @mizvekov wrote:

> In D128113#3744315 <https://reviews.llvm.org/D128113#3744315>, @alexfh wrote:
>
>> The whole project seems like a great improvement in clang diagnostics, but I don't yet see how template parameter pack substitution indices fit into the whole picture. If different type parameters in a parameter pack differ only by some other type of suraring, would they be distinguishable in the current state? How do substitution indices affect this?
>
> We need the pack index just as much as the index.
>
> When we are resugaring some type and we find a SubstTemplateParmType, first we try to find a template specialization in the current naming context (ie a nested name specifier) which refers to the same template as the Subst node.
>
> Then we have to rebuild that Subst node using, as the new underlying type, the template argument which appears in the template specialization we found. To find that argument, first we use the index, which already was available in the AST prior to this patch. But in case that index refers to an argument pack, then we need the pack index to be able to find the argument inside that.

I more or less understand the general direction, but it would be interesting to look at the specific code that uses this.

The main questions we need to answer here are:

1. is the cost of storing parameter pack substitution indices while building AST worth the benefits?
2. is there an alternative solution that would shift the cost to the moment when this information is about to be used (when formatting diagnostic, I suppose)?
3. is there a good way to make this cost optional (using a flag or somehow else)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128113/new/

https://reviews.llvm.org/D128113



More information about the cfe-commits mailing list