I've committed initial support for shorthand constraints. This patch
adds support for parsing a concept-names as non-class names. When
introducing a template parameter, the concept name is transformed into
a constraint on the template parameter. Constrained parameters can
introduce type, non-type
No, any current_template_reqs are reset (set to null) before parsing
any trailing requirements and restored after the fact.
Andrew Sutton
On Mon, Oct 7, 2013 at 3:05 PM, Jason Merrill ja...@redhat.com wrote:
OK.
If we have a friend declaration inside a constrained partial specialization,
The last patch introduced a regression. This ensures that we don't
generate false positives diagnosing errors in non-template contexts.
2013-10-07 Andrew Sutton andrew.n.sut...@gmail.com
* gcc/cp/cp-tree.h (check_constrained_friend): Take requirements as
an argument.
*
OK.
If we have a friend declaration inside a constrained partial
specialization, will that still get a false positive?
Jason
+ // Do not permit the declaration of constrained friend
+ // function declarations. They cannot be instantiated since
+ // the resulting declaration would never match the definition,
+ // which must be a non-template and cannot be constrained.
You're in
On 10/04/2013 09:20 AM, Andrew Sutton wrote:
Perhaps you mean that it must match a fully-instantiated function, so any
constraints on the templates were considered during
determine_specialization.
This seems like a simple comment fix, but there's a longer explanation
of what I want (see
Perhaps you mean that it must match a fully-instantiated function, so
any
constraints on the templates were considered during
determine_specialization.
This seems like a simple comment fix, but there's a longer explanation
of what I want (see below). Would this be more appropriate?
OK.
Jason
Hi Andrew,
On 10/04/2013 07:36 PM, Andrew Sutton wrote:
+ if (!check_template_constraints (tmpl, args))
+{
+ location_t loc = DECL_SOURCE_LOCATION (function);
+ error (%qD is not a viable candidate, function);
+ diagnose_constraints
This patch implements constrained friends and disallows declarations
of constrained friend template specialization.
There was a previous question about whether I was doing the right
thing in determine_specialization. I'm looking at that issue
separately.
2013-10-01 Andrew Sutton
On 10/02/2013 09:05 AM, Andrew Sutton wrote:
+ // Do not permit the declaration of constrained friend
+ // function declarations. They cannot be instantiated since
+ // the resulting declaration would never match the definition,
+ // which must be a
On 09/13/2013 12:21 PM, Andrew Sutton wrote:
Previously, if constraints were not
satisfied, we would not record the template as a candidate. However,
this causes errors in class template instantiation if there are
constrained friend declarations whose constraints are not satisfied
(no matching
I'm going to rewrite this patch tomorrow morning. The semantics aren't
quite right --- they should be simpler.
Previously, if constraints were not
satisfied, we would not record the template as a candidate. However,
this causes errors in class template instantiation if there are
constrained
On 09/21/2013 08:52 AM, Andrew Sutton wrote:
It is wrong, but not for the reasons I gave. This only happens when
you try to constrain a friend function that declares a specialization,
which happens to be completely separate from the previously declared
template.
I'm going to disallow the
This patch implements semantics for constrained friend templates and
classes. The only significant changes are in determine_specializaiton
and check_constrained_friend.
Unless a friend function is defined, a constraints on friend
declarations are never actually checked. The checking happens
This patch updates the maintainership of the c++-concepts and
var-template branches.
-- Gaby
Index: svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.188
diff -p -r1.188 svn.html
*** svn.html18 Aug
I added a new macro to replace the use of TREE_TYPE to get
constraints. It's called TEMPLATE_PARMS_CONSTRAINTS. Patch attached:
2013-09-10 Andrew Sutton andrew.n.sut...@gmail.com
* gcc/cp/cp-tree.h (TEMPLATE_PARMS_CONSTRAINTS): New.
* gcc/cp/parser.c
Andrew Sutton andrew.n.sut...@gmail.com writes:
| I added a new macro to replace the use of TREE_TYPE to get
| constraints. It's called TEMPLATE_PARMS_CONSTRAINTS. Patch attached:
|
| 2013-09-10 Andrew Sutton andrew.n.sut...@gmail.com
| * gcc/cp/cp-tree.h (TEMPLATE_PARMS_CONSTRAINTS): New.
Will amend and commit tomorrow morning!
Andrew
Andrew Sutton
On Tue, Sep 10, 2013 at 7:54 PM, Gabriel Dos Reis g...@axiomatics.org wrote:
Andrew Sutton andrew.n.sut...@gmail.com writes:
| I added a new macro to replace the use of TREE_TYPE to get
| constraints. It's called
Ok to commit? Attached is the doc fix patch. I'll send the TREE_TYPE
patch shortly.
Andrew
Andrew Sutton
On Sat, Sep 7, 2013 at 1:00 PM, Jason Merrill ja...@redhat.com wrote:
On 09/06/2013 12:03 PM, Andrew Sutton wrote:
+// Returns the template type of the class scope being entered. If we're
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Ok to commit? Attached is the doc fix patch. I'll send the TREE_TYPE
| patch shortly.
Yes, please -- that is what Jason earlier. Let me know when youve
committed so that I can synchronize with trunk.
-- Gaby
at revision 202396. No conflict.
-- Gaby
The last merge didn't compile for me. Apparently some pretty printing
functions have disappeared that were being called in the concept
stuff. This patch just replaces the broken calls to pp_cxx_type_id
with pp-type_id.
Ok to commit?
Andrew Sutton
fix.patch
Description: Binary data
Andrew Sutton andrew.n.sut...@gmail.com writes:
| The last merge didn't compile for me. Apparently some pretty printing
| functions have disappeared that were being called in the concept
| stuff. This patch just replaces the broken calls to pp_cxx_type_id
| with pp-type_id.
|
| Ok to commit?
On 09/06/2013 12:03 PM, Andrew Sutton wrote:
+// Returns the template type of the class scope being entered. If we're
+// entering a constrained class scope. TMPL is the most general template
+// of the scope being entered, and TYPE is its type.
TMPL is not part of the interface of
Updated as per comments.
I moved the resolve_template_scope function out to
finish_template_type. I couldn't figure out how to get the parsed
template parameter from the looked-up template in
lookup_class_template. That information may not be available outside
the parse state.
Andrew
Andrew
On 09/03/2013 11:01 AM, Andrew Sutton wrote:
Attached is a patch for constrained class templates. It's the 3rd time
I've sent it.
Please feel free to ping me if you're waiting for a patch review; once a
week is not too much.
1. Type constraints are checked on lookup rather than
1. Type constraints are checked on lookup rather than instantiation.
How is this different from function template constraints? Is this just a
difference in internal function name (instantiate_template vs
lookup_template_class)?
It's not supposed to be different. Checking constraints in
On 09/04/2013 11:59 AM, Andrew Sutton wrote:
It's not supposed to be different. Checking constraints in
instantiate_template is actually too late. We want to check before
instantiation, at the point of use.
Right, what I was getting at is that instantiate_template actually only
instantiates
It's not supposed to be different. Checking constraints in
instantiate_template is actually too late. We want to check before
instantiation, at the point of use.
Right, what I was getting at is that instantiate_template actually only
instantiates the declaration of a function, not the
On 09/04/2013 01:33 PM, Andrew Sutton wrote:
Ah. The goal is to check after we've deduced/coerced template
arguments into a valid substitution. With functions, that's in
fn_type_unification (hopefully called from instantiate_template)
Actually fn_type_unification calls instantiate_template,
Attached is a patch for constrained class templates. It's the 3rd time
I've sent it.
I added some fixes for bugs discovered after the previous send, and
added support for matching constrained declarations in out-of-class
member function definitions.
2013-08-02 Andrew Sutton
at revision 201992.
There were conflicts with the recent pretty printing patches.
Fixed. (Mostly due to the new concept-specific nodes printing.)
Modulo the asan stuff.
-- Gaby
The c++-concepts branch was synchronized with trunk at revision 201834.
-- Gaby
trunk was merged into c++-concepts branch at revision 201560.
I resolved some conflicts in cp caused by recent merges and ongoing work
on trunk.
-- Gaby
Attached is a patch that deals with class template constraints. In
particular, it does 3 things:
1. Type constraints are checked on lookup rather than instantiation.
2. Initial support for constrained out-of-class definitions is added
(more work needed)
3. Support for constrained partial template
Looks good.
Jason
Committed.
On Fri, Jul 26, 2013 at 10:27 PM, Gabriel Dos Reis g...@axiomatics.org wrote:
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Fixed and committed, but I have a small follow-up related to parameter
| packs in requires clauses. The checking for unexpanded parameter packs
| treats
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Committed.
Merge from trunk as of revision 201285.
We will have to watch out for Tom's Makefile rewrite work.
-- Gaby
Gaby == Gabriel Dos Reis g...@axiomatics.org writes:
Gaby We will have to watch out for Tom's Makefile rewrite work.
FWIW, I've found rebasing this series to be very easy.
Due to the way it is split up, only one patch (the big manual dependency
removal one) only ever has hard conflicts, and
Tom Tromey tro...@redhat.com writes:
| Gaby == Gabriel Dos Reis g...@axiomatics.org writes:
|
| Gaby We will have to watch out for Tom's Makefile rewrite work.
|
| FWIW, I've found rebasing this series to be very easy.
| Due to the way it is split up, only one patch (the big manual dependency
Fixed and committed, but I have a small follow-up related to parameter
packs in requires clauses. The checking for unexpanded parameter packs
treats the parameter declarations like regular PARM_DECL references
and gives errors that they are unexpanded packs.
2013-07-26 Andrew Sutton
This patch implements a new trait __is_same_as. This is foundational
for future work on concepts in that it provides a mechanism for
reasoning about type equivalences.
It also provides the correct preconditions for __is_convertible_to as
required in meta.rel.
2013-07-26 Andrew Sutton
Hi,
On 07/26/2013 02:11 PM, Andrew Sutton wrote:
This patch implements a new trait __is_same_as. This is foundational
for future work on concepts in that it provides a mechanism for
reasoning about type equivalences.
Isn't the name a little misleading? I immediately wondered what was
wrong
Isn't the name a little misleading? I immediately wondered what was wrong
with std::is_same. IMHO something a little longer/technical clarifying that
the trait isn't just about comparing types is in order...
Sure.
First, it means we don't have to instantiate any class templates in
order to
Hi,
On 07/26/2013 03:23 PM, Andrew Sutton wrote:
Isn't the name a little misleading? I immediately wondered what was wrong
with std::is_same. IMHO something a little longer/technical clarifying that
the trait isn't just about comparing types is in order...
Sure.
First, it means we don't have
Thanks a lot. Now I'm afraid that some of these nice clarifications,
delicate technical details included, may get lost. Do you think they exist
already in some of your design documents, papers, etc. Then a reference in
the code would do. Otherwise, please consider adding some of the above to
Makes sense.
Jason
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Fixed and committed, but I have a small follow-up related to parameter
| packs in requires clauses. The checking for unexpanded parameter packs
| treats the parameter declarations like regular PARM_DECL references
| and gives errors that they are
On 07/25/2013 10:19 AM, Andrew Sutton wrote:
+ pp_cxx_parameter_declaration_clause(pp, TREE_OPERAND (t, 0));
Space before (. Otherwise, looks good.
Jason
Trunk was merged to the c++-concept branch at revision 200958.
Andrew --
There aere a few conflicts surronding introduction of
can_convert_standard, between your version and the one Jason committed.
I resolved them in favour of Jason's because his version followed the
GNU coding convention (when
This should be merged with pp_cxx_parameter_declaration_clause.
+reqparms_to_string (tree p)
And this should have a more generic name.
I called this parms_to_string for symmetry with args_to_string. It
calls pp_cxx_parameter_declaration_clause.
+ if (check_requirements (t, args))
+
On 07/13/2013 05:37 AM, Andrew Sutton wrote:
There are two instantiations on purpose.
OK.
A lot of the new code in pt.c doesn't seem like it needs to be there; let's
put as much in constraint.cc as we can. Let's move some of the bits out of
semantics.c as well.
I think the
On 07/11/2013 02:59 PM, Andrew Sutton wrote:
pp_cxx_requirement_parameter_list (cxx_pretty_printer *pp, tree t)
This should be merged with pp_cxx_parameter_declaration_clause.
+reqparms_to_string (tree p)
And this should have a more generic name.
+ // requries clause.
requires
+
On 07/10/2013 08:24 AM, Andrew Sutton wrote:
That's a good idea. I changed every existing use of can_convert to
can_convert_standard for the time being. That will preserve the
existing behavior, and we can determine which of the existing uses can
include user-defined conversions later.
Let's
The attached patch finishes the semantics for requires expressions. It
includes reduction rules for constraint decomposition, substitution
rules, and diagnostics.
Andrew
Changelog:
2013-07-11 Andrew Sutton andrew.n.sut...@gmail.com
* gcc/cp/cp-tree.h (declare_local_parms): New
I ran through every test in the is_convertible unit test with
__is_convertible. There are 2 cases it doesn't address. The conversion
of a function type (int()) to its reference type (int()()),
I looked into this a bit more; it seemed odd to consider any conversion from
int() since there are
On 07/04/2013 11:30 AM, Andrew Sutton wrote:
I ran through every test in the is_convertible unit test with
__is_convertible. There are 2 cases it doesn't address. The conversion
of a function type (int()) to its reference type (int()()),
I looked into this a bit more; it seemed odd to consider
Unfortunately, the behavior differs from the test suite for
std::is_convertible. In particular, this fails:
static_assert(__is_convertible_to(int(int), int()(int)), );
whereas this succeeds )
static_assert(is_convertibleint(int), int()(int)::value, );
Hmm, that probably has to do with
On 07/01/2013 01:27 PM, Andrew Sutton wrote:
Unfortunately, the behavior differs from the test suite for
std::is_convertible. In particular, this fails:
static_assert(__is_convertible_to(int(int), int()(int)), );
whereas this succeeds )
static_assert(is_convertibleint(int),
Updated with corrections for previous comments. New patch attached,
but the Changelog is essentially the same.
+/* A unary expression representing a requirement for an expression that
+ can be evaluated at compile time. */
Judging from the implementation, it seems that this relies on the
I was not aware of that. That's probably the right, but I remember
having some troubles getting that to work the way I wanted in the
previous implementation. It seemed like I actually had to evaluate the
expression to determine if it was actually constexpr.
Right; an expression is a
This seems to assume that there is a result-type-requirement.
+// Returns true if type1 can be implicitly converted to type2.
+static inline bool
+convertible_to_p (tree type1, tree type2)
+{
+ // Build a fake conversion expression to force the lookup of user
+ // defined conversion
Just a couple of typos:
On 06/24/2013 11:56 AM, Andrew Sutton wrote:
+// Returns true if NEWDECL and OLDDEC are member functions with with
OLDDECL
+// different constraints. If NEWDECL and OLDDECL are non-template members
+// or specializations of non-template members, they overloads are
On 06/21/2013 10:59 AM, Andrew Sutton wrote:
+ sorry (cannot diagnose disjunctions just yet);
Use diagnose_other for the time being?
+
/* Langhook for print_error_function. */
void
cxx_print_error_function (diagnostic_context *context, const char *file,
@@ -3326,7 +3331,7 @@
On 06/21/2013 03:38 PM, Andrew Sutton wrote:
I haven't pushed this into a git branch since its a completely
separate change from the previous patch. Should I create a new branch
for separate work?
Sure.
Jason
On 06/21/2013 03:38 PM, Andrew Sutton wrote:
+ tree parms = cp_parser_parameter_declaration_clause (parser);
Calling this will push the parameter declarations into the current
binding level; you will want to add the begin_scope/leave_scope and
pop_binding that cp_parser_direct_declarator
On 06/25/2013 09:27 AM, Andrew Sutton wrote:
+/* The REQ expressions are unary expressions that specific inididual
specify?
+/* A unary expression representing a requirement for an expression that
+ may be evaluated at compile time. */
The word may is ambiguous and should be avoided in
Judging from the implementation, it seems that this relies on the notion of
potentially-constant expression which is no longer part of the standard;
that notion should only be used for diagnostics that are not required, not
for things that participate in the type system.
I think it would be
On 06/27/2013 04:56 PM, Andrew Sutton wrote:
I was not aware of that. That's probably the right, but I remember
having some troubles getting that to work the way I wanted in the
previous implementation. It seemed like I actually had to evaluate the
expression to determine if it was actually
I changed the method by which class (and alias) template constraints
are checked. Rather than waiting until instantiation, they are now
checked after computing the binding in lookup_class template.
Actually, after the hashtable lookup so we don't re-check constraints
for previously instantiated
Added a set of nodes to represent requirements inside of a requires
expression (EXPR_REQ, TYPE_REQ, NESTED_REQ), and a set of nodes
representing the actual checks of those requirements (VALIDEXPR_EXPR,
VALIDTYPE_EXPR, CONSTEXPR_EXPR).
The VALIDEXPR_EXPR, VALIDTYPE_EXPR, and CONSTEXPR_EXPR nodes
Adds initial support for matching constrained out-of-class member
function definitions to their declarations. Like so:
templatetypename T
struct S
{
void f(const T x)
requires CopyableT();
};
templatetypename T
void ST::f() requires CopyableT() { ... };
This does not a
On 06/21/2013 08:46 AM, Andrew Sutton wrote:
I can move those patches over to git and push the changes in separate
branches in addition to the usual submission mechanism. Would that be
appropriate? Can I create a bunch of different git branches for small
feature sets?
Sure, that sounds fine.
Revisions from previous patch.
I've taken constraint_info out of lang_decl_min and made it specific
to TEMPLATE_DECLs by saving it as DECL_SIZE_UNIT. It seems to be
unused for templates. When I start working on the shorthand notation,
I'll do something similar for template parameters and auto
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Revisions from previous patch.
|
| I've taken constraint_info out of lang_decl_min and made it specific
| to TEMPLATE_DECLs by saving it as DECL_SIZE_UNIT. It seems to be
| unused for templates. When I start working on the shorthand notation,
|
expression, not a nested requirement. I was
trying to subset the requirement like the Objective-C++ expressions
comment just below it.
I changed the comment to just C++ concepts. We may get other primary
expressions related to concepts, although I don't have any planned.
| +static inline tree
with nested
| requirements then.
|
| This denotes a primary expression, not a nested requirement. I was
| trying to subset the requirement like the Objective-C++ expressions
| comment just below it.
|
| I changed the comment to just C++ concepts. We may get other primary
| expressions related
| requirements then.
|
| This denotes a primary expression, not a nested requirement. I was
| trying to subset the requirement like the Objective-C++ expressions
| comment just below it.
|
| I changed the comment to just C++ concepts. We may get other primary
| expressions related to concepts
I changed the implementation to associate constraints with template
decls (actually lang_decl_min) rather than template_info.
The handling of constrained non-template member functions changes a
little. When a class template is instantiated the instantiated
requirements are associated directly
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Like this?
|
| // Parse a requires clause.
| //
| //requires-clause:
| // 'requires' logical-or-expression
| //
| // The required logical-or-expression must be a constant expression.
| static tree
| cp_parser_requires_clause (cp_parser
On Sat, Jun 22, 2013 at 10:57 AM, Andrew Sutton
andrew.n.sut...@gmail.com wrote:
I changed the implementation to associate constraints with template
decls (actually lang_decl_min) rather than template_info.
Hmm, why move it to lang_decl_min? Now, every C++ declaration will
have a constraint,
I the long term, I think we'll end up having constraints attached to
declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
Although now that I'm looking, it seems that lang_decl_parm does not
inherit lang_min. Hmm...
Mostly, though, I'm not sure where I could put it where both
Andrew Sutton andrew.n.sut...@gmail.com writes:
| I the long term, I think we'll end up having constraints attached to
| declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
| Although now that I'm looking, it seems that lang_decl_parm does not
| inherit lang_min. Hmm...
|
|
On Sat, Jun 22, 2013 at 12:11 PM, Gabriel Dos Reis g...@axiomatics.org wrote:
Andrew Sutton andrew.n.sut...@gmail.com writes:
| I the long term, I think we'll end up having constraints attached to
| declarations wherever we constrain auto (PARM_DECL, VAR_DECL, etc).
| Although now that I'm
Internally, we want to always store the canonical form of a decl, not the
source-level form -- the current g++ AST isn't prepared for that (I wish
it was, but it isn't.) This allows for simple comparison and other
semantics processing.
Agreed. But without some source-level annotations in the
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Internally, we want to always store the canonical form of a decl, not the
| source-level form -- the current g++ AST isn't prepared for that (I wish
| it was, but it isn't.) This allows for simple comparison and other
| semantics processing.
| Agreed. But without some source-level annotations in the tree, I don't
| think I can generate the diagnostics that programmer's might otherwise
| expect. I'd have to emit the internal representation.
Do you have examples where we don't do or we can't do the obvious thing
in terms of
* We have to avoid increasing memory consumption for regular C++ codes
that do not use concepts lite. This is an important criteria. We
have only one front-end that is invoked in C++03, C++11, C++14, and
C++17 modes. Almost all existing codes are C++03, C++11, and even
C++14 only and
Andrew --
At revision 200343.
With the merge of Cilk changes to trunk, it was necessary to synchronize
so that c++-concepts branch doesn't get too out of sync. There were a
few conflicts in cp/Make-lang.in and cp/cp-tree.h that I think I
resolved properly. Let me know if anything else
On Mon, Jun 3, 2013 at 6:15 PM, Jason Merrill ja...@redhat.com wrote:
On 06/01/2013 10:57 AM, Gabriel Dos Reis wrote:
Well, we don't want to check cxx0x one place and cxx11 others.
But we still do.
Testing a patch.
-- Gaby
| Previous discussion seemed to indicate that saving constraints with
| template decls was preferable.
Yes; exactly.
| The committed version in the branch carries those constraints in
| template_info for the temploid.
Yes; I think that is good.
So we should associate constraints with
| But, I don't think we have a single TEMPLATE_PARM_DECL node. Template
| parameters are either TYPE_DECLs or PARM_DECLs. I think auto
| declarations, get VAR_DECLs, but I haven't looked closely at that
| design. I'd have to look to see if there are any free tree slots all
| of those decl nodes
| But, I don't think we have a single TEMPLATE_PARM_DECL node. Template
| parameters are either TYPE_DECLs or PARM_DECLs. I think auto
| declarations, get VAR_DECLs, but I haven't looked closely at that
| design. I'd have to look to see if there are any free tree slots all
| of those decl
Andrew Sutton andrew.n.sut...@gmail.com writes:
| | Previous discussion seemed to indicate that saving constraints with
| | template decls was preferable.
|
| Yes; exactly.
|
| | The committed version in the branch carries those constraints in
| | template_info for the temploid.
|
| Yes;
Andrew Sutton andrew.n.sut...@gmail.com writes:
| | But, I don't think we have a single TEMPLATE_PARM_DECL node. Template
| | parameters are either TYPE_DECLs or PARM_DECLs. I think auto
| | declarations, get VAR_DECLs, but I haven't looked closely at that
| | design. I'd have to look to see
I think I will continue to work from SVN branches, because I'm a lot
more familiar with that process. I'm also going to start working on a
couple of different checkouts of the c++-concepts branch
independently, so this should be a little easier for me.
I can move those patches over to git
a reasonable number of error messages). But I
think the general algorithm is essentially the right approach. I did
this differently in an early version, and it was much more cumbersome.
Changes are pushed in git branch asutton/c++-concepts. The Changelog is below:
2013-06-20 Andrew Sutton
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Changes are pushed in git branch asutton/c++-concepts. The Changelog
| is below
Andrew, please can you send me a diff? When reading emails, it really is
much easier for me that way. Thanks,
-- Gaby
Shoot. Forgot to attach the patch...
Andrew
On Fri, Jun 21, 2013 at 10:17 AM, Gabriel Dos Reis g...@axiomatics.org wrote:
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Changes are pushed in git branch asutton/c++-concepts. The Changelog
| is below
Andrew, please can you send me a diff
101 - 200 of 277 matches
Mail list logo
