[Bug c++/102419] New: [concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[Bug c++/102419] New: [concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[arthur.j.odwyer at gmail dot com]

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

            Bug ID: 102419
           Summary: [concepts] [regression] return-type-requirement of
                    "Y<typename T::type>" does not check that T::type
                    actually exists
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/GWjYYnrnM
template<class, class> concept Y = true;
template<class T> concept X = requires {
    { 1 } -> Y<typename T::type>;
};
static_assert(!X<int>);


<source>:8:15: error: static assertion failed
    8 | static_assert(!X<int>);
      |               ^~~~~~~

Clang and MSVC both appear to have the correct behavior -- or what I believe to
be the consistent/useful/majority behavior, anyway -- which is that since
T::type doesn't exist, the concept shouldn't be satisfied.

This seems to be a regression; according to Godbolt, GCC 10.3 had the correct
behavior but GCC 11.1 lost it. 

I wonder if #92268 could be related somehow, since it seems to be something
like the inverse issue (nonexistent nested type causing a hard error in 10.x),
and it was marked fixed presumably somewhere in the 11.x timeframe.

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
      Known to fail|                            |11.1.0
      Known to work|                            |10.3.0
   Target Milestone|---                         |11.3
            Summary|[concepts] [regression]     |[11/12
                   |return-type-requirement of  |Regression][concepts]
                   |"Y<typename T::type>" does  |[regression]
                   |not check that T::type      |return-type-requirement of
                   |actually exists             |"Y<typename T::type>" does
                   |                            |not check that T::type
                   |                            |actually exists

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[ppalka at gcc dot gnu.org]

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

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

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

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The behavior of this testcase was changed with r11-7454 (the testcase
concepts-return-req2.C added there is essentially identical to this one). 
Before this commit, we'd substitute template arguments into the
return-type-requirement before checking satisfaction, and now we substitute
template arguments as part of satisfaction (into the normal form of the
constraint, which is just 'true (with an empty parameter mapping)'), which
explains the behavior change.

AFAICT, the standard is inconsistent about whether a separate substitution
should be performed here.  On the one hand, [expr.prim.req.compound] says

  - Substitution of template arguments (if any) into the
return-type-requirement is performed.

which suggests a separate substitution should be performed.  On the other hand,
the example in that same section says a compound-requirement is equivalent to a
simple-requirement & nested-requirement:

  Given concepts C and D,

    requires {
      { E1 } -> C;
      { E2 } -> D<A1, ⋯, An>;
    };

  is equivalent to

  requires {
    E1; requires C<decltype((E1))>;
    E2; requires D<decltype((E2)), A1, ⋯, An>;
  };

and we certainly shouldn't be doing a separate substitution when checking a
nested-requirement.  IIUC, GCC's behavior is consistent with the example.

Generally GCC tries to avoid doing a separate substitution into a constraint
whenever we can get away with it and instead perform the substitution as part
of satisfaction.  This e.g. also occurs for the type-constraint of a 
placeholder type:

  template<class, class> concept Y = true;
  template<class T> void f() {
    Y<typename T::type> auto y = 0;
  }
  template void f<int>(); // GCC accepts, Clang/MSVC reject

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[ppalka at gcc dot gnu.org]

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

--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Note that you can make GCC effectively behave like Clang/MSVC here changing Y's
constraint-expression to trivially depend on its template parameter:

  template<class, class U> concept Y = requires { typename U; };

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
And similarly for:

  template<class> concept Y = true;
  template<class T> concept X = Y<typename T::type>;
  static_assert(!X<int>);

GCC rejects and Clang/MSVC accept.  IMHO Clang/MSVC are clearly misbehaving
here -- when evaluating the concept-id X<int>, they appear to be substituting
{int} into X's constraint-expression instead of into the normal form of X's
constraint-expression.

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[arthur.j.odwyer at gmail dot com]

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

--- Comment #4 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
> IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the concept-id X<int>, they appear to be substituting {int} into X's constraint-expression instead of into the normal form of X's constraint-expression.

Isn't this situation exactly analogous to `std::void_t`?

  template<class T> using void_t = void;
  template<class T> auto foo(T t) -> void_t<typename T::type>;  // SFINAEs away
  template<class T> auto foo(T t) -> int;  // this is the only viable candidate
  static_assert(std::same_as<decltype(foo(1)), int>);

The language has definitely decided that you can't preemptively fold
`void_t<some-dependent-expression>` down to `void`; I don't think you should be
allowed to preemptively fold `Y<some-dependent-expression>` down to `true`,
either.
I don't know for sure that Clang/MSVC have been authoritatively dubbed
righteous, but their behavior certainly seems, to me, more consistent and
useful than GCC's.

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Arthur O'Dwyer from comment #4)
> > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the concept-id X<int>, they appear to be substituting {int} into X's constraint-expression instead of into the normal form of X's constraint-expression.
> 
> Isn't this situation exactly analogous to `std::void_t`?
> 
>   template<class T> using void_t = void;
>   template<class T> auto foo(T t) -> void_t<typename T::type>;  // SFINAEs
> away
>   template<class T> auto foo(T t) -> int;  // this is the only viable
> candidate
>   static_assert(std::same_as<decltype(foo(1)), int>);
> 
> The language has definitely decided that you can't preemptively fold
> `void_t<some-dependent-expression>` down to `void`;

True, that 
I don't think you should
> be allowed to preemptively fold `Y<some-dependent-expression>` down to
> `true`, either.
> I don't know for sure that Clang/MSVC have been authoritatively dubbed
> righteous, but their behavior certainly seems, to me, more consistent and
> useful than GCC's.

(In reply to Arthur O'Dwyer from comment #4)
> > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the concept-id X<int>, they appear to be substituting {int} into X's constraint-expression instead of into the normal form of X's constraint-expression.
> 
> Isn't this situation exactly analogous to `std::void_t`?
> 
>   template<class T> using void_t = void;
>   template<class T> auto foo(T t) -> void_t<typename T::type>;  // SFINAEs
> away
>   template<class T> auto foo(T t) -> int;  // this is the only viable
> candidate
>   static_assert(std::same_as<decltype(foo(1)), int>);
> 
> The language has definitely decided that you can't preemptively fold
> `void_t<some-dependent-expression>` down to `void`; I don't think you should
> be allowed to preemptively fold `Y<some-dependent-expression>` down to
> `true`, either.

I see what you mean, but I think the constraint normalization process as
currently specified forces us to effectively perform such folding. 
Specifically in the definition of an atomic constraint
([temp.constr.atomic]p1):

  An atomic constraint is formed from an expression E and a mapping from the
template parameters that appear within E to template arguments that are formed
via substitution during constraint normalization in the declaration of a
constrained entity.

the parameter mapping of an atomic constraint is defined to consist only of the
template parameters that _appear within E_.  In this case E is just 'true',
which doesn't depend on any template parameters, so the normal form of
Y<typename T::type> is just 'true (with empty parameter mapping)', which is
trivially satisfied for all T.

In order to achieve the behavior that you expect, IIUC this definition would
need to be changed to say that the parameter mapping of an atomic constraint
includes all in-scope template parameters and not only those that appear within
the expression.

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/102419] [11/12 Regression][concepts] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org
            Summary|[11/12                      |[11/12
                   |Regression][concepts]       |Regression][concepts]
                   |[regression]                |return-type-requirement of
                   |return-type-requirement of  |"Y<typename T::type>" does
                   |"Y<typename T::type>" does  |not check that T::type
                   |not check that T::type      |actually exists
                   |actually exists             |

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
Concept satisfaction was very deliberately designed in committee discussion to
work differently from void_t, based on the normalized form rather than the
concept-id as written.  So this example is well-formed:

template <class Tz> concept is_void = same_as(Tz, void);
template <class Ta, class Tb> concept void_or_same = is_void<Ta> || same_as<Ta,
Tb>;
template <class T> void f() requires void_or_same<T,T&>;
int main() { f<void>(); } // OK

It definitely is an inconsistency with non-concept template-ids, but that's the
design.

C++20 national body comment CA104
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2103r0.html#CA104) is
about one situation where we do need to substitute directly into the arguments,
but it is a single exception to the rule.

In the discussion of CA104 I suggested that we might want to reconsider this
design (on 2019-11-08, if you want to look up the reflector message), and make
my example above ill-formed, but we ended up making an exception instead.

The behavior change you are seeing is from properly implementing
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1452r2.html and not a
bug.

[Bug c++/102419] [11/12 Regression][concepts] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

[Bug c++/102419] [11/12 Regression][concepts] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

[Bug c++/102419] [11/12/13 Regression][concepts] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cjdb.ns at gmail dot com

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

[Bug c++/102419] [11/12/13/14 Regression][concepts] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.

[Bug c++/102419] [11/12/13/14 Regression][concepts] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |novulae at hotmail dot com

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