This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/71965] New: [7 regression] [concepts] Substitution error *after* failure to satisfy an earlier constraint


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

            Bug ID: 71965
           Summary: [7 regression] [concepts] Substitution error *after*
                    failure to satisfy an earlier constraint
           Product: gcc
           Version: 7.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Casey at Carter dot net
  Target Milestone: ---

Created attachment 38949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38949&action=edit
Repro

p121R0 [temp.constr.op]/2 states: "... The satisfaction of a conjunction’s
operands are evaluated left-to-right; if the left operand is not satisfied,
template arguments are not substituted into the right operand, and the
constraint is not satisfied. ..."

So this program:

template <class T>
concept bool Destructible() {
    return false;
}

template <class T, class...Args>
concept bool ConstructibleObject =
    Destructible<T>() && requires (Args&&...args) {
        new T{ (Args&&)args... };
    };

int main() {
    using T = int[2][2];
    static_assert(!ConstructibleObject<T, T>);
}

Should compile without diagnostics, as is the case with GCC 6. GCC 7 (r238631),
however, diagnoses substitution failure in the "new" expression despite that
the "Destructible<T>()" constraint is unsatisfied:

casey@Semiregular:~$ ~/gcc-r238631/bin/g++ -std=c++1z -fconcepts
dev/cmcstl2/repro.cpp
dev/cmcstl2/repro.cpp: In function ‘int main()’:
dev/cmcstl2/repro.cpp:9:9: sorry, unimplemented: cannot initialize
multi-dimensional array with initializer
         new T{ (Args&&)args... };
         ^~~~~~~~~~~~~~~~~~~~~~~~

"Hiding" the requires clause inside another named concept is sufficient to
workaround the problem.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]