[Bug c++/105699] New: [Concepts] Constrained virtual functions are accepted by GCC

[Bug c++/105699] New: [Concepts] Constrained virtual functions are accepted by GCC

[roi.jacobson1 at gmail dot com]

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

            Bug ID: 105699
           Summary: [Concepts] Constrained virtual functions are accepted
                    by GCC
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: roi.jacobson1 at gmail dot com
  Target Milestone: ---

[class.virtual]p6 says virtual functions shall not be constrained. This example
from the standard is accepted in GCC:

template<typename T>
struct A {
  virtual void f() requires true; // Standard says is an error
};

Is this intentional?

[Bug c++/105699] [Concepts] Constrained virtual functions are accepted by GCC

[roi.jacobson1 at gmail dot com]

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

--- Comment #1 from Roy Jacobson <roi.jacobson1 at gmail dot com> ---
I want to suggest to also consider the case of overloading virtual functions
with non-virtual constrained functions. There's an open CWG issue about this
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2488 and the ABI
implications are very annoying. MSVC already forbid it.

It interacts very funnily with the special member functions paper (P0848).
Consider

template<int N>
struct A {
  A& operator=(A&&) requires true;
  virtual A& operator=(A&&);
};

template<int N>
struct B {
  B& operator=(B&&) requires false;
  virtual B& operator=(B&&);
};

template<int N>
struct C {
  ~C() requires true;
  virtual ~C();
};

template<int N>
struct D {
  ~D() requires false;
  virtual ~D();
};

template<int N>
struct E {
  void foo() requires false;
  virtual void foo();
};

template<int N>
struct F {
  void foo() requires false;
  virtual void foo();
};

Currently GCC will generate vtables for B,D, and for both E and F, which seems
wrong. (I think C shouldn't have a vtable but A probably should have one, if
I'm interpreting P0848 correctly).

[Bug c++/105699] [Concepts] Constrained virtual functions are accepted by GCC

[fchelnokov at gmail dot com]

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

--- Comment #2 from Fedor Chelnokov <fchelnokov at gmail dot com> ---
Another aspect is that the order of destructors in the class change its
behavior:

#include <type_traits>

template<int N>
struct X {
  ~X() requires (N==1);
  virtual ~X();
};

// X is NOT polymorphic in GCC
static_assert( !std::is_polymorphic_v<X<1>> );

template<int N>
struct Y {
  virtual ~Y();
  ~Y() requires (N==1);
};

// Y is polymorphic in GCC
static_assert( std::is_polymorphic_v<Y<1>> );

Demo: https://gcc.godbolt.org/z/493qr5K9d

[Bug c++/105699] [Concepts] Constrained virtual functions are accepted by GCC

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |67491
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-05-24


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/105699] [Concepts] Constrained virtual functions are accepted by GCC

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|https://gcc.gnu.org/bugzill |
                   |a/show_bug.cgi?id=103865    |

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 103865 has been marked as a duplicate of this bug. ***