[Bug c++/95310] New: [concepts] Unrelated template parameters printed in diagnostic

[Bug c++/95310] New: [concepts] Unrelated template parameters printed in diagnostic

[ensadc at mailnesia dot com]

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

            Bug ID: 95310
           Summary: [concepts] Unrelated template parameters printed in
                    diagnostic
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ensadc at mailnesia dot com
                CC: asutton at gcc dot gnu.org
  Target Milestone: ---

https://godbolt.org/z/M8CVwc

====
template <class T>
using iter_reference_t = decltype(*T{});

template <typename F>
struct result {
  using type = iter_reference_t<F>;
};

template <class Out, class T>
concept indirectly_writable = requires(Out&& o, T&& t) {
  iter_reference_t<Out>(*o) = 0;
};
static_assert(indirectly_writable<const int*, int&>);

====
<source>:13:15: error: static assertion failed
   13 | static_assert(indirectly_writable<const int*, int&>);
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:13:15: note: constraints not satisfied
<source>:10:9:   required by the constraints of 'template<class Out, class T>
concept indirectly_writable'
<source>:10:31:   in requirements with 'Out&& o', 'T&& t' [with F = const int*;
T = int&; Out = const int*]
<source>:11:29: note: the required expression 'decltype(*{})(*o)=0' is invalid
   11 |   iter_reference_t<Out>(*o) = 0;
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail

====
Note "[with F = const int*; T = int&; Out = const int*]". The 'F = const int*;'
part is spurious.

When the template parameter of `result` has the same name as the parameter of
the concept (which is the case I originally encountered), the output can be
quite confusing.

The expression 'decltype(*{})(*o)=0' also seems wrong.

Might be related to bug 94862.

[Bug c++/95310] [concepts] Unrelated template parameters printed in diagnostic

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-05-27
     Ever confirmed|0                           |1
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Confirmed.

[Bug c++/95310] [concepts] Unrelated template parameters printed in diagnostic

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk by r11-3372-d6587211c02c4e2566c4e545c09757f3fbb7adab

[Bug c++/95310] [concepts] Unrelated template parameters printed in diagnostic

[ensadc at mailnesia dot com]

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

--- Comment #3 from ensadc at mailnesia dot com ---
When verifying the fix, I noticed a new bug:

====
template <class T> requires true
using iter_reference_t = decltype(*T{});

template <typename F>
struct result {
  using type = iter_reference_t<F>;
};

template <class Out, class T>
concept indirectly_writable = requires(Out&& o, T&& t) {
  iter_reference_t<Out>(*o) = 0;
};

template<class In, class Out>
requires indirectly_writable<Out, iter_reference_t<In>>
void copy(In in, Out out) {}

void test(const int* p, int* q) {
    copy(q, p);
}

====
<source>: In function 'void test(const int*, int*)':
<source>:19:14: error: no matching function for call to 'copy(int*&, const
int*&)'
   19 |     copy(q, p);
      |              ^
<source>:16:6: note: candidate: 'template<class In, class Out>  requires 
indirectly_writable<Out, decltype(*{})> void copy(In, Out)'
   16 | void copy(In in, Out out) {}
      |      ^~~~
<source>:16:6: note:   template argument deduction/substitution failed:
<source>:16:6: note: constraints not satisfied
<source>: In substitution of 'template<class In, class Out>  requires 
indirectly_writable<Out, decltype(*{})> void copy(In, Out) [with In = int*; Out
= const int*]':
<source>:19:14:   required from here
<source>:10:9:   required for the satisfaction of 'indirectly_writable<Out,
iter_reference_t<F> >' [with Out = const int*; In = int*]
<source>:10:31:   in requirements with 'Out&& o', 'T&& t' [with T = int&; Out =
const int*]
<source>:11:29: note: the required expression 'decltype(*{})(*o)=0' is invalid
   11 |   iter_reference_t<Out>(*o) = 0;
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail
====

In

  <source>:10:9:   required for the satisfaction of 'indirectly_writable<Out,
iter_reference_t<F> >' [with Out = const int*; In = int*]

Note the mismatch between `F` and `In`.

GCC 10.2 prints `F = int*` instead of `In = int*`:

  <source>:10:9:   required for the satisfaction of 'indirectly_writable<Out,
iter_reference_t<F> >' [with Out = const int*; F = int*]

The name `F` comes from a completely unrelated class template, but at least the
names match in GCC 10.2.

(Interestingly, the alias template is not expanded in this line.)

[Bug c++/95310] [concepts] Unrelated template parameters printed in diagnostic

[ppalka at gcc dot gnu.org]

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

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to ensadc from comment #3)
> When verifying the fix, I noticed a new bug:

Thanks for the heads up.

> 
> ====
> template <class T> requires true
> using iter_reference_t = decltype(*T{});
> 
> template <typename F>
> struct result {
>   using type = iter_reference_t<F>;
> };
> 
> template <class Out, class T>
> concept indirectly_writable = requires(Out&& o, T&& t) {
>   iter_reference_t<Out>(*o) = 0;
> };
> 
> template<class In, class Out>
> requires indirectly_writable<Out, iter_reference_t<In>>
> void copy(In in, Out out) {}
> 
> void test(const int* p, int* q) {
>     copy(q, p);
> }
> 
> ====
> <source>: In function 'void test(const int*, int*)':
> <source>:19:14: error: no matching function for call to 'copy(int*&, const
> int*&)'
>    19 |     copy(q, p);
>       |              ^
> <source>:16:6: note: candidate: 'template<class In, class Out>  requires 
> indirectly_writable<Out, decltype(*{})> void copy(In, Out)'
>    16 | void copy(In in, Out out) {}
>       |      ^~~~
> <source>:16:6: note:   template argument deduction/substitution failed:
> <source>:16:6: note: constraints not satisfied
> <source>: In substitution of 'template<class In, class Out>  requires 
> indirectly_writable<Out, decltype(*{})> void copy(In, Out) [with In = int*;
> Out = const int*]':
> <source>:19:14:   required from here
> <source>:10:9:   required for the satisfaction of 'indirectly_writable<Out,
> iter_reference_t<F> >' [with Out = const int*; In = int*]
> <source>:10:31:   in requirements with 'Out&& o', 'T&& t' [with T = int&;
> Out = const int*]
> <source>:11:29: note: the required expression 'decltype(*{})(*o)=0' is
> invalid
>    11 |   iter_reference_t<Out>(*o) = 0;
>       |   ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
> cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
> detail
> ====
> 
> In
> 
>   <source>:10:9:   required for the satisfaction of
> 'indirectly_writable<Out, iter_reference_t<F> >' [with Out = const int*; In
> = int*]
> 
> Note the mismatch between `F` and `In`.
> 
> GCC 10.2 prints `F = int*` instead of `In = int*`:
> 
>   <source>:10:9:   required for the satisfaction of
> 'indirectly_writable<Out, iter_reference_t<F> >' [with Out = const int*; F =
> int*]
> 
> The name `F` comes from a completely unrelated class template, but at least
> the names match in GCC 10.2.
> 
> (Interestingly, the alias template is not expanded in this line.)

Hmm, so the r11-3373 patch fixed only the printing of template parameters
within the constraint's parameter mapping, i.e. within the [with ...] part of
the diagnostic.  But as your latest testcase shows, within the diagnostic the
constraint itself could also refer to an unrelated template parameter.  To fix
this part of the diagnostic I think we would have to more generally fix PR66968
once and for all..