[Bug c++/104255] New: parsing trailing return type fails with parameter pack expansion when two parameter packs at present

[Bug c++/104255] New: parsing trailing return type fails with parameter pack expansion when two parameter packs at present

[nickhuang99 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

            Bug ID: 104255
           Summary: parsing trailing return type fails with parameter pack
                    expansion when two parameter packs at present
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

The following template function causes error when we define trailing return
type which is identical to what function body actual returning
( https://www.godbolt.org/z/n3nbW785o ) 

template<size_t N, size_t...Is>
constexpr size_t identity2(index_sequence<Is...>seq){
        return N;
}
template<size_t...Seq1, size_t...Seq2>
auto getSeq2(index_sequence<Seq1...>seq1, index_sequence<Seq2...>seq2)
// this trailing return type causing parsing error of parameter pack
->index_sequence<(identity2<Seq1, Seq2...>(seq2))...>;
{
        return index_sequence<(identity2<Seq1, Seq2...>(seq2))...>{};
}


As a positive example against above, when "identity1" takes no parameter pack
as template argument, it works fine.

template<size_t N>
constexpr size_t identity1(){
        return N;
}
template<size_t...Indexes>
auto getSeq1(index_sequence<Indexes...>indexes)
// trailing return type works, no need to define function body at all.
->index_sequence<(identity1<Indexes>())...>;


clang13/MSVC all work as expected.

[Bug c++/104255] parsing trailing return type fails with parameter pack expansion when two parameter packs at present

[nickhuang99 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

--- Comment #1 from qingzhe huang <nickhuang99 at hotmail dot com> ---
Just a FYI, this version is a bit simplified from this original code.
(https://www.godbolt.org/z/n7ajzr46f) because this is an actual meaningful
function to reverse a given index_sequence. You can see if trailing return type
works, it doesn't need to define the function body so that the template
function works exactly like a meta function.


template<size_t...Indexes, size_t...Numbers>
auto get_reverse_sequence_helper(index_sequence<Indexes...>indexes, 
            index_sequence<Numbers...>numbers)
// If this trailing return type is OK, we don't need actually define 
// function body.
->index_sequence< (getSeqByIndex<Indexes, Numbers...>(numbers))... >
{
    return index_sequence< (getSeqByIndex<Indexes, Numbers...>(numbers))...
>{};
}

[Bug c++/104255] parsing trailing return type fails with parameter pack expansion when two parameter packs at present

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The error message is obscure, but it seems what GCC has issue with here is the
use of the function parameter seq2 in the trailing return type occurring
outside of an unevaluated context.

I'm not totally sure if the testcase is valid
(https://eel.is/c++draft/basic.scope.param#note-1 might suggest it's not?), but
one workaround is to replace the use of seq2 in the trailing return type with
decltype(seq2){} (which works because index_sequence is an empty type).

Here's a minimal testcase demonstrating the issue

  struct empty { };
  constexpr int f(empty) { return 0; }
  template<int> struct A { };
  auto g(empty e) -> A<f(e)>;

which is rejected with

  error: use of parameter outside function body before ‘)’ token

due to 'e' being used outside of an unevaluated context within the signature of
the function.

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[nickhuang99 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

--- Comment #3 from qingzhe huang <nickhuang99 at hotmail dot com> ---
(In reply to Patrick Palka from comment #2)
> The error message is obscure, but it seems what GCC has issue with here is
> the use of the function parameter seq2 in the trailing return type occurring
> outside of an unevaluated context.
> 
The error messages are issued in a cascading fashion, the "outside function
parameter" is issued much later which maybe far-fetched from core one, in my
guess.


> I'm not totally sure if the testcase is valid
> (https://eel.is/c++draft/basic.scope.param#note-1 might suggest it's not?),
> but one workaround is to replace the use of seq2 in the trailing return type
> with decltype(seq2){} (which works because index_sequence is an empty type).

This is about "parameter-declaration-clause" which is not our case, because
"f(e)" is not function declaration part, instead an invoking of function of
which "e" is not "declaration" at all, but an argument of function.


> Here's a minimal testcase demonstrating the issue
> 
>   struct empty { };
>   constexpr int f(empty) { return 0; }
>   template<int> struct A { };
>   auto g(empty e) -> A<f(e)>;

Again, GCC is only one rejecting this code
(https://www.godbolt.org/z/1bvMavKKd) which makes me suspect that GCC may not
be correct.


> which is rejected with
> 
>   error: use of parameter outside function body before ‘)’ token
> 
> due to 'e' being used outside of an unevaluated context within the signature
> of the function.

BTW, this has nothing to do with c++20(no -std=c++20 is needed) which
eliminates potential issues of many c++20 new features. Thank you for your
simplified case which is a much clearer one to demonstrate the core issue.

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[nickhuang99 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

--- Comment #4 from qingzhe huang <nickhuang99 at hotmail dot com> ---
(In reply to Patrick Palka from comment #2)

> 
>   error: use of parameter outside function body before ‘)’ token
> 
> due to 'e' being used outside of an unevaluated context within the signature
> of the function.

Sorry for my being unable to grasp your meaning before. Now I can see your
point that the "e" of A<f(e)> is from declaration of parameter of function "g".
Now that we agree the value from parameter clause should not be used in
trailing return type, then it should also not be used in requires clause etc. 
(https://eel.is/c++draft/basic.scope.param#1.3)
But this works:

template<typename T>
auto f(int n) requires (n>0);

This is violating our assumption. So, I am not convinced that 
(https://eel.is/c++draft/basic.scope.param#note-1)
"A function parameter cannot be used for its value within the
parameter-declaration-clause" is really meaningful. Or I misunderstand it???


https://www.godbolt.org/z/759oGdr94

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to qingzhe huang from comment #4)
> (In reply to Patrick Palka from comment #2)
> 
> > 
> >   error: use of parameter outside function body before ‘)’ token
> > 
> > due to 'e' being used outside of an unevaluated context within the signature
> > of the function.
> 
> Sorry for my being unable to grasp your meaning before. Now I can see your
> point that the "e" of A<f(e)> is from declaration of parameter of function
> "g". Now that we agree the value from parameter clause should not be used in
> trailing return type, then it should also not be used in requires clause
> etc. 
> (https://eel.is/c++draft/basic.scope.param#1.3)
> But this works:
> 
> template<typename T>
> auto f(int n) requires (n>0);

That's because the constraint-expression of a requires clause is an unevaluated
operand (wg21.link/temp.pre#9.sentence-4).  (Though I think this example is
strictly speaking ill-formed no diagnostic required because the constraint can
never be satisfied (wg21.link/temp.res.general#6.2).)

The check in question is in finish_id_expression_1:

      /* Also disallow uses of function parameters outside the function
         body, except inside an unevaluated context (i.e. decltype).  */
      if (TREE_CODE (decl) == PARM_DECL
          && DECL_CONTEXT (decl) == NULL_TREE
          && !cp_unevaluated_operand)
        {
          *error_msg = G_("use of parameter outside function body");
          return error_mark_node;
        }

> 
> This is violating our assumption. So, I am not convinced that 
> (https://eel.is/c++draft/basic.scope.param#note-1)
> "A function parameter cannot be used for its value within the
> parameter-declaration-clause" is really meaningful. Or I misunderstand it???

We should probably relax the above check to permit uses of function parameters
with empty types even outside of unevaluated contexts, since we don't really
care about the value of an empty type.

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hewillk at gmail dot com

--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 111712 has been marked as a duplicate of this bug. ***

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fchelnokov at gmail dot com

--- Comment #7 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 112448 has been marked as a duplicate of this bug. ***

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-11-08

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[barry.revzin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255

Barry Revzin <barry.revzin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |barry.revzin at gmail dot com

--- Comment #8 from Barry Revzin <barry.revzin at gmail dot com> ---
(In reply to Patrick Palka from comment #2)
> The error message is obscure, but it seems what GCC has issue with here is
> the use of the function parameter seq2 in the trailing return type occurring
> outside of an unevaluated context.
> 
> I'm not totally sure if the testcase is valid
> (https://eel.is/c++draft/basic.scope.param#note-1 might suggest it's not?),

But we're not using the parameter for its "value" here (which I think means in
the sense of lvalue-to-rvalue conversion... as in reading a parameter of type
int), so I don't think this would be a reason to reject?