================
@@ -160,3 +160,22 @@ namespace GH88929 {
using E = P...[0]; // expected-error {{unknown type name 'P'}} \
// expected-error {{expected ';' after alias
declaration}}
}
+
+namespace GH88925 {
+template <typename...> struct S {};
+
+template <int...> struct sequence {};
+
+template <typename... Args, int... indices> auto f(sequence<indices...>) {
+ return S<Args...[indices]...>(); // #use
+}
+
----------------
zyn0217 wrote:
> ```cpp
> template <auto...> struct S2 {};
> template <auto... Args, int... indices> auto f(sequence<indices...>) {
> return S2<Args...[indices]...>(); // #use
> }
> ```
OK, so the problem here is *not* the same: we end up [classifying the
`PackIndexingExpr`'s
category](https://github.com/llvm/llvm-project/blob/338561657685c1831a53563b1bc36ffc7470239e/clang/lib/AST/ExprClassification.cpp#L219-L220)
while deducing against the NTTP of `S2`. This happens before the instantiation
of `f`, and therefore `Args...[indices]...` is still dependent.
I *guess* we can perceive dependent `PackIndexingExprs` as LValues in such
cases, like what we did for `UnresolvedLookupExpr`. Additionally, P2662 now
limits them to id-expressions only, and hence we can probably always treat them
as LValues?
https://github.com/llvm/llvm-project/pull/90195
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
