[Bug c++/97704] New: [11 Regression][concepts] Not working with explicit types in function signatures?

[Bug c++/97704] New: [11 Regression][concepts] Not working with explicit types in function signatures?

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

            Bug ID: 97704
           Summary: [11 Regression][concepts] Not working with explicit
                    types in function signatures?
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hi gcc-team,

consider the following program:

```c++
struct non_exisiting {};

template <typename t>
auto hard_error(t in)
{
    static_assert(in, "Failure");
    return;
}

template <typename t>
    requires requires { hard_error(t{}); }
constexpr auto foo(t, non_exisiting);

template <typename t>
constexpr auto foo(t, bool) { return false; };

int main()
{
    foo(0, false);
};
```

This worked since at least g++-7 up until g++-10.2, works with clang (11 and
trunk), as well as msvc.

I would expect that `foo(t, non_exisiting)` will not be considered, because it
would not be meaningful in this case (`bool` is not of type `non_exisiting` and
there is no conversion sequence from `bool` to `non_exisiting`).

See https://godbolt.org/z/3W5eG8

I hope this is a bug and not intended behaviour, because I encountered this
problem by using a range adaptor from the stdlib inside a templated class which
all of a sudden found `operator|` (a hidden friend of that range adaptor) by
ADL even though that operator did not match signature-wise.

If this is intended behaviour, what in world is the type of the second
parameter of `foo(t, non_exisiting)`?

Thank you!

[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I forgot to add the error message:

```
<source>: In instantiation of 'auto hard_error(t) [with t = int]':

<source>:11:35:   required by substitution of 'template<class t>  requires
requires{hard_error({});} constexpr auto foo(t, non_exisiting) [with t = int]'

<source>:19:17:   required from here
<source>:6:19: error: non-constant condition for static assertion
    6 |     static_assert(in, "Failure");
      |                   ^~

<source>:6:19: error: 'in' is not a constant expression
```

(For some reasons godbolt shows everything in the compliance view as green,
this link https://godbolt.org/z/Go8Mc5 should also show the compiler error)

[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
   Target Milestone|---                         |11.0

[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-11-19
     Ever confirmed|0                           |1
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r11-2774, before that we compiled the code.  clang++ compiles it
fine too.

[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you, Marek Polacek for finding that revision.

I checked out the master branch and reverted the commit
f1612b8ae8a60f62cf5456b3357a341550534a7e and now everything compiles again.

So that, regression is definitely coming from that commit.

[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?

[jason at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
As mentioned in the commit message, this change is the result of CWG issue
2369:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2369

Which moved checking of non-dependent conversions after checking the
constraints for satisfaction.  The rationale is that checking non-dependent
conversions can also cause unwanted instantiations, and unwanted instantiations
from satisfaction checking can be worked around by adding additional
constraints, but constraints can only prevent unwanted instantiations from
conversion checking if the constraints are checked first.

Probably the standard library needs to add some constraints.