[Bug c++/65854] New: [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211824

[Bug c++/65854] New: [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211824

[tom at honermann dot net]

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

            Bug ID: 65854
           Summary: [c++-concepts] Type constraint satisfaction error for
                    type aliases; regression from r211824
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tom at honermann dot net

The following test case demonstrates what I believe to be an error in type
constraint satisfaction involving type aliases.  I believe the code should be
rejected with the noted error.  I have an old gcc build (r211824) that does
reject it (though the 'typename' keyword in the concept definition must be
removed for the compiler to reject it for the correct reason).  gcc r222333
(incorrectly) accepts it.

The test case defines a binary type trait template class (BTT), an alias
template that references it (Alias), a concept (C) that specifies a type
constraint using the alias, and declares a template function (f) that requires
the concept for its template parameters.  The call to f<char,int>() should be
rejected due to a failure of the type constraint in C (BTT<char,int>::type
won't exist), but gcc r222333 fails to reject.

Changing the concept to bypass the template alias and require 'typename
BTT<T1,T2>::type' instead suffices for gcc r222333 to correctly reject the
code.

$ cat t.cpp
template<typename T1, typename T2>
struct BTT {};
template<typename T>
struct BTT<T,T> {
    using type = int;
};

template<typename T1, typename T2>
using Alias = typename BTT<T1, T2>::type;

template<typename T1, typename T2>
concept bool C() {
    return requires() {
               typename Alias<T1, T2>;
           };
}

template<typename T1, typename T2>
requires C<T1, T2>()
int f();

auto i = f<char, int>(); // error: cannot call function

$ svn info   # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 222333
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 222332
Last Changed Date: 2015-04-22 12:08:55 -0400 (Wed, 22 Apr 2015)

$ g++ -c -std=c++1z t.cpp 
<no error>

# Using an older gcc r211824 build (and having removed the 'typename' keyword
# preceding Alias in the concept definition that this old build didn't allow),
# the code is rejected (though the error message is a little off).  (note
# that this old build required -std=c++1y to enable support for concepts).
$ g++ -c -std=c++1y t.cpp
t.cpp:22:23: error: no matching function for call to ‘f()’
 auto i = f<char, int>();
                       ^
t.cpp:20:5: note: candidate: template<class T1, class T2> int f()
 int f();
     ^
t.cpp:20:5: note:   template argument deduction/substitution failed:
t.cpp:20:5: note:   constraints not satisfied  [with T1 = char; T2 = int]
t.cpp:20:5: note:   failure in constraint ‘template<class T1, class T2>
constexpr bool C()’
t.cpp:20:5: note:     ‘BTT<char, int>::Alias’ does not name a valid type
>From gcc-bugs-return-484416-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 23 03:40:44 2015
Return-Path: <gcc-bugs-return-484416-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10668 invoked by alias); 23 Apr 2015 03:40:44 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10608 invoked by uid 48); 23 Apr 2015 03:40:39 -0000
From: "tom at honermann dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65848] [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824
Date: Thu, 23 Apr 2015 03:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tom at honermann dot net
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-65848-4-CX9g0DGFml@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65848-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65848-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg01968.txt.bz2
Content-length: 1194

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide848

Tom Honermann <tom at honermann dot net> changed:

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

--- Comment #3 from Tom Honermann <tom at honermann dot net> ---
Thank you.  Confirmed fixed with r222332.  My resource usage compiling the test
case now closely matches the usage noted in comment 2.

(In reply to Andrew Sutton from comment #1)
> This is caused by the use of a concept outside of a requires clause -- it's
> still a bug though. The TS doesn't actually include wording that would allow
> this program to be valid.

Ah, I wasn't aware of that restriction.

> Unfortunately, the first thing people do when they have concepts it to write
> tests that statically assert them, so I've been extending the proposal to
> make that valid.

I think that is actually not so unfortunate.  Statically asserting concept
models has helped me find numerous issues in my own code.  I'm glad to hear the
proposal is being extended to cover this.

[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591

[tom at honermann dot net]

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

Tom Honermann <tom at honermann dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[c++-concepts] Type         |[c++-concepts] Type
                   |constraint satisfaction     |constraint satisfaction
                   |error for type aliases;     |error for type aliases;
                   |regression from r211824     |regression from r211591

--- Comment #1 from Tom Honermann <tom at honermann dot net> ---
A correction.  I've been reading the svn info details incorrectly.  The old gcc
build I have that accepts this code is r211591, not r211824.  Updated the
summary.

[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591

[andrew.n.sutton at gmail dot com]

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

--- Comment #2 from Andrew Sutton <andrew.n.sutton at gmail dot com> ---
Confirmed. Parsing a type requirement that names an alias template was giving
back a declaration, which wasn't being instantiated correctly. 

r222769 unwraps the type from the declaration and will correctly reject the
test case.

[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591

[tom at honermann dot net]

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

Tom Honermann <tom at honermann dot net> changed:

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

--- Comment #3 from Tom Honermann <tom at honermann dot net> ---
Thank you!  I confirmed that this is corrected with r222769.  Changing status
to resolved/fixed.