Attached is the stubbed out parsing for requires expressions. I plan
on implementing semantics next.
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?
Changelog:
2013-06-21 Andrew Sutton
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Shoot. Forgot to attach the patch...
|reinit_cxx_pp ();
| - dump_template_decl (TREE_PURPOSE (p), flags);
| + if (decl)
| +{
| + dump_template_decl (decl, flags);
|pp_cxx_whitespace (cxx_pp);
| +}
Watch out for
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Attached is the stubbed out parsing for requires expressions. I plan
| on implementing semantics next.
See comments below.
| I haven't pushed this into a git branch since its a completely
| separate change from the previous patch. Should I
On 06/20/2013 01:30 AM, Gabriel Dos Reis wrote:
As I discussed
with Andrew a couple of weeks ago, I have been holding back the
merge from trunk because he has these patch series in the queue.
Incidentally, since the code is going onto a branch, we don't really
need to delay checkins based on
Jason Merrill ja...@redhat.com writes:
| On 06/20/2013 01:30 AM, Gabriel Dos Reis wrote:
| As I discussed
| with Andrew a couple of weeks ago, I have been holding back the
| merge from trunk because he has these patch series in the queue.
|
| Incidentally, since the code is going onto a
That works. I think the current patch addresses all of Jason's comments.
I'll also create a github version of this branch, so can avoid email patches.
On Thu, Jun 20, 2013 at 8:09 AM, Gabriel Dos Reis g...@axiomatics.org wrote:
Jason Merrill ja...@redhat.com writes:
| On 06/20/2013 01:30 AM,
On 06/20/2013 09:18 AM, Andrew Sutton wrote:
I'll also create a github version of this branch, so can avoid email patches.
Why there rather than in the gcc.gnu.org git repository?
http://gcc.gnu.org/wiki/GitMirror
Jason
I didn't know it existed! Even better. Except that I'm not a git
expert. I'm reading through the docs on that site while I clone the
repo.
It looks like I should be able to switch directly to the c++-concepts
branch. Or is there some configuration that has to happen on the
remote site?
How
On 06/20/2013 10:17 AM, Andrew Sutton wrote:
It looks like I should be able to switch directly to the c++-concepts
branch. Or is there some configuration that has to happen on the
remote site?
The c++-concepts SVN branch won't come in with a clone; you need to add
it to the fetch list
Andrew Sutton andrew.n.sut...@gmail.com writes:
| That works. I think the current patch addresses all of Jason's comments.
OK, that sounds good.
| I'll also create a github version of this branch, so can avoid email patches.
Well, actually I prefer the email patches because I can read them
Jason Merrill ja...@redhat.com writes:
| On 06/20/2013 10:17 AM, Andrew Sutton wrote:
| It looks like I should be able to switch directly to the c++-concepts
| branch. Or is there some configuration that has to happen on the
| remote site?
|
| The c++-concepts SVN branch won't come
On 06/20/2013 11:22 AM, Gabriel Dos Reis wrote:
Jason Merrill ja...@redhat.com writes:
| On 06/20/2013 10:17 AM, Andrew Sutton wrote:
| It looks like I should be able to switch directly to the c++-concepts
| branch. Or is there some configuration that has to happen on the
| remote site
Jason Merrill ja...@redhat.com writes:
| On 06/20/2013 11:22 AM, Gabriel Dos Reis wrote:
| Jason Merrill ja...@redhat.com writes:
|
| | On 06/20/2013 10:17 AM, Andrew Sutton wrote:
| | It looks like I should be able to switch directly to the c++-concepts
| | branch. Or is there some
The c++-concepts SVN branch won't come in with a clone; you need to add it
to the fetch list with
git config --add remote.origin.fetch
refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts
Then you can check out a local branch based on it.
Already did that. I probably need to do
On 06/20/2013 11:50 AM, Andrew Sutton wrote:
The c++-concepts SVN branch won't come in with a clone; you need to add it
to the fetch list with
git config --add remote.origin.fetch
refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts
Then you can check out a local branch based
On 06/20/2013 01:23 PM, Jason Merrill wrote:
Since Gaby prefers SVN, let's keep using the SVN branch; it really isn't
much less convenient than a git-only branch. The main difference is
'git svn rebase'/'git svn dcommit' instead of 'git pull'/'git push'.
The one caveat is that git-svn
At revision 200282.
Andrew --
there was a slight conflict with the new usage of is_binary_trait.
I think I resolved it properly, but double check.
-- Gaby
On 06/18/2013 12:27 PM, Andrew Sutton wrote:
There was a bug in instantiation_dependent_expr_r that would cause
trait expressions like __is_class(int) to be marked as type dependent.
It was always testing the 2nd operand, even for unary traits
(NULL_TREE turns out to be type dependent).
I
+// If the types of the underlying templates match, compare
+// their constraints. The declarations could differ there.
+if (types_match)
+ types_match = equivalent_constraints (get_constraints
(olddecl),
+
, even for unary traits
(NULL_TREE turns out to be type dependent).
I fixed that last month:
2013-05-20 Jason Merrill ja...@redhat.com
PR c++/57016
* pt.c (instantiation_dependent_r) [TRAIT_EXPR]: Only check
type2 if there is one.
The last merge to c++-concepts
2. I left the cstdlib include in system.h, because removing it will
result in errors due to an inclusion of algorithm. It's probable
that both can be removed, but I didn't test it with this patch.
You mean you don't need algorithm anymore in logic.cc? I think we want
the cstdlib include in
On 06/17/2013 02:10 PM, Andrew Sutton wrote:
You mean you don't need algorithm anymore in logic.cc? I think we want
the cstdlib include in general if we're going to support people using the
C++ standard library.
I don't. Those decisions are above my pay grade, so I'm doing my best
not to make
On Mon, Jun 17, 2013 at 2:20 PM, Jason Merrill ja...@redhat.com wrote:
I have not thought deeply about constrained friend declarations. What
would a friend temploid look like?
I was thinking something like
template class T struct A {
T t;
requires AddableT()
friend A
1. tree_template_info still contains constraint_info. That will change
in a subsequent patch. I'm kind of waiting for specializations to get
TEMPLATE_DECLs.
Makes sense.
2. I left the cstdlib include in system.h, because removing it will
result in errors due to an inclusion of algorithm. It's
On Fri, Jun 14, 2013 at 8:40 PM, Jason Merrill ja...@redhat.com wrote:
+// \Gamma, P |- Delta\Gamma, Q |- \Delta
Are the \ for TeX markup or something? You're missing one on the left Delta
here.
yes, I think the backslash was for LaTeX, but we get warnings about having
backslash in
On Mon, Jun 10, 2013 at 2:30 PM, Jason Merrill ja...@redhat.com wrote:
On 06/08/2013 09:34 AM, Andrew Sutton wrote:
I think I previously put constraint_info in lang_decl_min, right next
to template_info no less. It was easy to manage there, and initialized
as part of build_template_decl. But
On 06/12/2013 11:53 AM, Gabriel Dos Reis wrote:
I am still surprised though that we don't generate TEMPLATE_DECLs for
partial instantiations (since they are still morally templates.)
Yes, we should.
Jason
I think I previously put constraint_info in lang_decl_min, right next
to template_info no less. It was easy to manage there, and initialized
as part of build_template_decl. But this obviously doesn't work for
partial specializations unless they get template_decls.
Right. And we would want
On 06/11/2013 09:45 AM, Andrew Sutton wrote:
After investigating, neither call_expr nor resolve_nondeduced_context
do what I need. I need a resolution of a call expression that does not
return overload sets, especially in the case where the initial call
expression is already dependent.
Does
After investigating, neither call_expr nor resolve_nondeduced_context
do what I need. I need a resolution of a call expression that does not
return overload sets, especially in the case where the initial call
expression is already dependent.
Does this have to do with restrictions on
On 06/11/2013 10:49 AM, Andrew Sutton wrote:
After investigating, neither call_expr nor resolve_nondeduced_context
do what I need. I need a resolution of a call expression that does not
return overload sets, especially in the case where the initial call
expression is already dependent.
Does
And you need to do this even when the call is type-dependent?
Yes. Especially when the call is type-dependent. That's how I generate
the constraint sets, which are used to determine the most constrained
template during overload resolution.
On 06/11/2013 11:09 AM, Andrew Sutton wrote:
And you need to do this even when the call is type-dependent?
Yes. Especially when the call is type-dependent. That's how I generate
the constraint sets, which are used to determine the most constrained
template during overload resolution.
Ah,
On 2013-06-09 20:34 , Gabriel Dos Reis wrote:
So, my advice is for GCC source code to forget about the cxxx
headers for the most part. I can see an instance where cmath or cstring
would make a difference but given point (1) above, no it doesn't.
Just use the traditional xxx.h headers and be
On 06/09/2013 08:34 PM, Gabriel Dos Reis wrote:
I strongly suggest prefering stdlib.h over cstdlib for GCC source code
base.
The problem is that including stdlib.h does not define
_GLIBCXX_CSTDLIB, so if one of the C++ library headers includes
cstdlib the contents are added then, but by that
On 06/09/2013 08:49 PM, Gabriel Dos Reis wrote:
If you put the function in an unnamed namespace
you would expect GCC to treat is as if it was of internal
linkage for many purposes including automatic inlining, but
it doesn't:-( For example, you lose the defined but not used
warning, and the
On 06/08/2013 09:34 AM, Andrew Sutton wrote:
I think I previously put constraint_info in lang_decl_min, right next
to template_info no less. It was easy to manage there, and initialized
as part of build_template_decl. But this obviously doesn't work for
partial specializations unless they get
On 6/10/13, Diego Novillo dnovi...@google.com wrote:
On 2013-06-09 20:34 , Gabriel Dos Reis wrote:
So, my advice is for GCC source code to forget about the cxxx
headers for the most part. I can see an instance where cmath
or cstring would make a difference but given point (1) above,
no
On Thu, 2013-06-06 at 16:29 -0400, Jason Merrill wrote:
On 06/06/2013 01:47 PM, Andrew Sutton wrote:
I never did understand why this happens. Compiling with GCC-4.6, I get
these errors originating in logic.cc from an include of algorithm.
This is what I get:
On Sun, Jun 9, 2013 at 3:34 PM, Oleg Endo oleg.e...@t-online.de wrote:
On Thu, 2013-06-06 at 16:29 -0400, Jason Merrill wrote:
On 06/06/2013 01:47 PM, Andrew Sutton wrote:
I never did understand why this happens. Compiling with GCC-4.6, I get
these errors originating in logic.cc from an
On Sat, Jun 8, 2013 at 8:34 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote:
templateterm_list (*proj)(proof_goal)
tree
extract_goals (proof_state s)
...
return extract_goalsassumptions(s);
but I suppose STL style is OK, too.
Huh. I didn't realize that could be inlined. Neat.
We do
+C++ ObjC++ Var(flag_concepts, true)
This line declares flag_concepts implicitly.
Ah... I see. Fixed.
That's the long and short of it. Gaby suggested writing constraints
here so that, for any instantiation, you would have easy access to the
constraints for that declaration.
I'm not sure
| D_CXXWARN },
+ { requires,RID_REQUIRES, D_CXXONLY | D_CXX0X | D_CXXWARN },
I don't see anything that limits these keywords to when concepts are
enabled. You probably want to add an additional mask that applies to these.
+; Activate C++ concepts support.
+Variable
+bool flag_concepts
,
from ../../c++-concepts/gcc/cp/logic.cc:45:
/usr/include/c++/4.6/cstdlib:76:8: error: attempt to use poisoned calloc
/usr/include/c++/4.6/cstdlib:83:8: error: attempt to use poisoned malloc
/usr/include/c++/4.6/cstdlib:89:8: error: attempt to use poisoned realloc
/usr/include/c++/4.6
the include gets the mentions of malloc in before the
names are poisoned. This change is OK.
+; Activate C++ concepts support.
+Variable
+bool flag_concepts
You don't need to declare this separately.
I'm not quite sure what you mean. Separately from what?
Separately from
+C++ ObjC
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. I'd rather fix that all together in a separate patch
than mess with it in this context.
Jason
* Check against cxx11 dialect, not cxx0x.
This check is actually all over parser.c, the reason it shows up in
the patch is that I reverted a previous change that affected some code
that included it.
I'd feel better leaving it in, since its a change that could affect
some other part of the
On Sat, Jun 1, 2013 at 6:56 AM, Andrew Sutton andrew.n.sut...@gmail.com wrote:
* Check against cxx11 dialect, not cxx0x.
This check is actually all over parser.c, the reason it shows up in
the patch is that I reverted a previous change that affected some code
that included it.
I'd feel
This patch adds constraint checking and overloading for function
templates, class templates, and alias templates. This patch isn't as
big as it seems, it just touches the compiler in a lot of different
places.
2013-06-01 Andrew Sutton andrew.n.sut...@gmail.com
* gcc/cp/call.c
Andrew Sutton andrew.n.sut...@gmail.com writes:
| This is a kind of large patch. It provides support for parsing
| constraints, the new concept declaration specifier (with some
| semantics implemented), and the infrastructure for creating and
| comparing constraints.
See comments below. Patch
* Check against cxx11 dialect, not cxx0x.
Let's talk about this tomorrow. I'm not quite sure how to do this.
* Any particular reason to use classes with operator() for the
parseers and the combinators? GCC can inline indirect calls to
functions with internal linkage. That
Andrew Sutton andrew.n.sut...@gmail.com writes:
|* Check against cxx11 dialect, not cxx0x.
|
| Let's talk about this tomorrow. I'm not quite sure how to do this.
|
|* Any particular reason to use classes with operator() for the
| parseers and the combinators? GCC can inline
I'll clean it up and commit tomorrow morning.
Once you've committed the patch, let me know so I can synchronize with
trunk -- or is there another patch coming in this week?
I'm hoping to get all of the function-related functionality sent off
by tomorrow or Saturday. I found a showstopper in
On 05/30/2013 03:17 PM, Andrew Sutton wrote:
| - /* 1 spare bit */
| + unsigned concept_p : 1; /* var or fn */
| + /* 0 spare bit */
| };
Hmm I don't understand the comment var or fn.
If it is declared a concept, how can it it be a var?
Copied from the other bits in the
I presented that at C++Now, so I hope so :) It lets me write:
templatetypename T
requires Input_iteratorT // no parens!
void f(T x);
Walter Brown also suggested this usage in his object alias paper.
In concepts lite, a concept is essentially an expression. Thus far,
we've packaged those
Andrew Sutton andrew.n.sut...@gmail.com writes:
| I presented that at C++Now, so I hope so :) It lets me write:
|
| templatetypename T
| requires Input_iteratorT // no parens!
| void f(T x);
|
| Walter Brown also suggested this usage in his object alias paper.
|
| In concepts lite, a
Trunk was merged into c++-concepts branch at revision 198984.
-- Gaby
Trunk as been merged into the c++-concepts branch.
-- Gaby
Associate requirements with declarations. This introduces a new node
(constraint-info) stores requirements and (eventually) decomposed
assumptions for all C++ declaration types. Template constraints are
associated with template declarations (including aliases and template
template parameters) and
Andrew,
As we discussed a couple of days ago, this patch defaults us to C++1y.
Applied to branch.
-- Gaby
2013-03-29 Gabriel Dos Reis g...@integrable-solutions.net
* c-common.c (cxx_dialect): Default to C++1y.
Index: gcc/c-family/c-common.c
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Implements reduction of requirements into the constraints language:
| logical formulas comprised of atomic propositions. Calls to constraint
| predicates are recursively inlined in the resulting expression. All
| other calls are treated as atoms.
Andrew Sutton andrew.n.sut...@gmail.com writes:
| Implements reduction of requirements into the constraints language:
| logical formulas comprised of atomic propositions. Calls to constraint
| predicates are recursively inlined in the resulting expression. All
| other calls are treated as atoms.
The trunk was merged into the c++-concepts branch as of revision 197225.
-- Gaby
Implements reduction of requirements into the constraints language:
logical formulas comprised of atomic propositions. Calls to constraint
predicates are recursively inlined in the resulting expression. All
other calls are treated as atoms.
2013-03-01 Andrew Sutton andrew.n.sut...@gmail.com
I've merged changes from trunk into the c++-concepts branch as of
revision 196857. These include Jason's patch to stop randomness
in linkage name of entities defined at unnamed namespace scopes.
-- Gaby
Adding initial support for the semantic analysis of template
requirements. This patch adds features for reducing requires clauses
into logical formulas comprised only of atomic propositions and
logical connectives.
The next patch will add inlining for constraint predicates.
I had hoped to add
This patch enables C++11 and concepts support by default on the
c++-concepts branch.
-- Gaby
2013-03-01 Gabriel Dos Reis g...@integrable-solutions.net
* gcc/c-family/c-common.c (cxx_dialect): Set C++11 as default.
* gcc/c-family/c.opt(flag_concepts): Add.
* gcc/cp
===
--- gcc/cp/lex.c(revision 196384)
+++ gcc/cp/lex.c(working copy)
@@ -51,9 +51,6 @@
/* A constraint that can be tested at compile time. */
#define CONSTRAINT(name, expr) extern int constraint_##name [(expr) ? 1 : -1]
-/* True if C++ concepts are enabled
Two patches attached.
The reqs-parsing patch adds parsing support for template requirements
(i.e., requires clauses). This is supported for all template
declarations and non-template member functions of class templates.
Grammar changes are documented in comments. Semantic processing of
On Fri, Mar 1, 2013 at 10:12 AM, Andrew Sutton
andrew.n.sut...@gmail.com wrote:
Two patches attached.
The reqs-parsing patch adds parsing support for template requirements
(i.e., requires clauses). This is supported for all template
declarations and non-template member functions of class
Reserving a handful of new keywords for concepts and several new type
traits in preparation for future work on concepts.
Andrew
2013-02-05 Andrew Sutton andrew.n.sut...@gmail.com
* c-common.h (rid): New resreserved words for concepts.
* c-common.c (c_common_reswords):
): New resreserved words for concepts.
* c-common.c (c_common_reswords): Definitions thereof.
For all patches for the c++-concepts branch, CC: me and Jason.
Can we also have corresponding documentation for the new keywords?
E.g. in doc/extend.texi. For the moment, you probably just want
in preparation for future work on concepts.
Andrew
2013-02-05 Andrew Sutton andrew.n.sut...@gmail.com
* c-common.h (rid): New resreserved words for concepts.
* c-common.c (c_common_reswords): Definitions thereof.
For all patches for the c++-concepts branch, CC: me
(c_common_reswords): Definitions thereof.
For all patches for the c++-concepts branch, CC: me and Jason.
Can we also have corresponding documentation for the new keywords?
E.g. in doc/extend.texi. For the moment, you probably just want to add
a menu node for C++ concepts, and list these new
(c_common_reswords): Definitions thereof.
For all patches for the c++-concepts branch, CC: me and Jason.
Can we also have corresponding documentation for the new keywords?
E.g. in doc/extend.texi. For the moment, you probably just want to add
a menu node for C++ concepts, and list these new tokens as reserved
...@gmail.com
* c-common.h (rid): New resreserved words for concepts.
* c-common.c (c_common_reswords): Definitions thereof.
For all patches for the c++-concepts branch, CC: me and Jason.
Can we also have corresponding documentation for the new keywords?
E.g. in doc/extend.texi
Hi,
I've created a new branch, called c++-concepts for work being done
for C++ concepts (yes, again.) This new effort is unrelated to
previous ConceptGCC so I left alone the inactive branch c++0x-concepts.
The patch below has been committed.
Thanks,
-- Gaby
Index: svn.html
201 - 277 of 277 matches
Mail list logo
