[Bug c++/103760] New: Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[Bug c++/103760] New: Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[jacek.olczyk98 at gmail dot com]

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

            Bug ID: 103760
           Summary: Invalid expression inside lambda inside compound
                    requirement causes an error instead of concept
                    satisfaction failure
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jacek.olczyk98 at gmail dot com
  Target Milestone: ---

When using a lambda expression in a requires clause compound requirement,
placing an expression invalid for some type T inside the lambda causes a
compile error during instantiation, instead of the expected behavior of causing
the concept to not be satisfied.
On clang, the behavior is as expected.

This happens on 10.2, where I discovered it, as well as on trunk. 
Here is the code: https://godbolt.org/z/EnK5G8Yjf

To save a click, the example code is:

template<typename T>
concept Concept = requires (T x) {
    {[](){ return T::foo; }()};
};
static_assert(!Concept<int>);



The expected behavior is to pass the static_assert.
The actual error is:

<source>: In lambda function:
<source>:3:22: error: 'foo' is not a member of 'int'
    3 |     {[](){ return T::foo; }()};
      |                      ^~~

[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
MSVC also rejects this code for the same reason as GCC ...

[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[ppalka at gcc dot gnu.org]

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

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> ---
GCC's behavior appears to be correct here (though perhaps less useful than
Clang's).  According to wg21.link/temp.deduct.general#9 a lambda expression
isn't part of the immediate context, so substitution failure from within the
lambda ought to be a hard error, not a SFINAE error.  Note that Clang also
doesn't reject the first four examples from that paragraph.

[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So not a bug, even though the use of lambda here would be useful, it is not
part of the standard :).

[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[jacek.olczyk98 at gmail dot com]

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

--- Comment #4 from Jacek Olczyk <jacek.olczyk98 at gmail dot com> ---
(In reply to Patrick Palka from comment #2)
> GCC's behavior appears to be correct here (though perhaps less useful than
> Clang's).  According to wg21.link/temp.deduct.general#9 a lambda expression
> isn't part of the immediate context, so substitution failure from within the
> lambda ought to be a hard error, not a SFINAE error.  Note that Clang also
> doesn't reject the first four examples from that paragraph.

Forgive me if I'm wrong (it's my first time reading into the standard), but
this seems to be from a section explicitly talking about function templates,
not templates in general - and function templates seem to be somewhat of a
special case in many ways. I have not, however, been able to find the portion
of the standard which delves into the relevant behavior in other templates.

[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Jacek Olczyk from comment #4)
> (In reply to Patrick Palka from comment #2)
> > GCC's behavior appears to be correct here (though perhaps less useful than
> > Clang's).  According to wg21.link/temp.deduct.general#9 a lambda expression
> > isn't part of the immediate context, so substitution failure from within the
> > lambda ought to be a hard error, not a SFINAE error.  Note that Clang also
> > doesn't reject the first four examples from that paragraph.
> 
> Forgive me if I'm wrong (it's my first time reading into the standard), but
> this seems to be from a section explicitly talking about function templates,
> not templates in general - and function templates seem to be somewhat of a
> special case in many ways. I have not, however, been able to find the
> portion of the standard which delves into the relevant behavior in other
> templates.

That's a fair point, it's my understanding that the standard doesn't very
clearly define SFINAE in the first place (e.g. the standard uses but never
defines the term "immediate context", which is an open issue
wg21.link/cwg1844).

But at least in the case, we can also seek guidance from the proposal paper for
unevaluated lambdas, wg21.link/p0315.  At the top of page 7 the paper discusses
using lambdas inside constraints and comes to the same conclusion.

[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[ppalka at gcc dot gnu.org]

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

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

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

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

[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[danakj at orodu dot net]

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

danakj at orodu dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danakj at orodu dot net

--- Comment #7 from danakj at orodu dot net ---
MSVC and Clang both accept this code, which GCC rejects. Is it the same issue
and GCC is compliant here?

```
#include <concepts>

template <class T>
concept C = requires() {
    {
        [](T t) constexpr { t.foo(1); }()
    };
};

void bad_call(const char*);

struct Foo {
    consteval void foo(int i) {
        if (i > 0) {
            bad_call("positive_value");
        }
    }
};

static_assert(!C<Foo>);
```

https://godbolt.org/z/bdrPve4rT

[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to danakj from comment #7)
> MSVC and Clang both accept this code, which GCC rejects. Is it the same
> issue and GCC is compliant here?

I think so because of this part:
"so substitution failure from within the lambda ought to be a hard error, not a
SFINAE error." In this case the substitution within a constexpr/consteval
lambda to fail.