deprecated in GCC 14
and removed for GCC 15). So there's not much to salvage from this
section besides the __is_same trait documentation which we can
conveniently move to the previous Type Traits section.
OK.
gcc/ChangeLog:
* doc/extend.texi (C++ Concepts): Remove section.
). So there's not much to salvage from this
section besides the __is_same trait documentation which we can
conveniently move to the previous Type Traits section.
gcc/ChangeLog:
* doc/extend.texi (C++ Concepts): Remove section. Move
__is_same documentation to the previous Type T
duplicate_decls was not recognizing the explicit specialization as matching
the implicit specialization of g because
function_requirements_equivalent_p was seeing the C constraint on the
implicit one and not on the explicit.
I think that the usefulness of much of the concepts TS support is limited
I discovered that we'd accept constraints on block-scope function
decls inside templates. This fixes that.
gcc/cp/
* decl.c (grokfndecl): Don't attach to local extern.
gcc/testsuite/
* concepts/local-extern.C: New.
pushed to trunk
nathan
--
Nathan Sidwell
diff
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
on this template with a pair of dtors, with
mutually exclusive "requires" clauses:
templ
On 2/13/19 9:36 AM, David Malcolm wrote:
Ping
yes, sorry didn't realize you were waiting on me.
On Fri, 2019-02-08 at 12:03 -0500, David Malcolm wrote:
Ping
On Fri, 2019-01-25 at 15:02 -0500, David Malcolm wrote:
On Fri, 2019-01-25 at 08:59 -0800, Nathan Sidwell wrote:
On 1/25/19 8:48 AM
Ping
On Fri, 2019-02-08 at 12:03 -0500, David Malcolm wrote:
> Ping
>
> On Fri, 2019-01-25 at 15:02 -0500, David Malcolm wrote:
> > On Fri, 2019-01-25 at 08:59 -0800, Nathan Sidwell wrote:
> > > On 1/25/19 8:48 AM, David Malcolm wrote:
> > > > PR c++/89036 reports an ICE due to this assertion fai
Ping
On Fri, 2019-01-25 at 15:02 -0500, David Malcolm wrote:
> On Fri, 2019-01-25 at 08:59 -0800, Nathan Sidwell wrote:
> > On 1/25/19 8:48 AM, David Malcolm wrote:
> > > PR c++/89036 reports an ICE due to this assertion failing
> > >
> > > 1136/* A class should never have more than one
>
On Fri, 2019-01-25 at 08:59 -0800, Nathan Sidwell wrote:
> On 1/25/19 8:48 AM, David Malcolm wrote:
> > PR c++/89036 reports an ICE due to this assertion failing
> >
> > 1136 /* A class should never have more than one
> > destructor. */
> > 1137 gcc_assert (!current_fns || via_u
On 1/25/19 8:48 AM, David Malcolm wrote:
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
on this template with a pair of dtors, with
mu
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
on this template with a pair of dtors, with
mutually exclusive "requires" clauses:
templ
OK.
On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini wrote:
> Hi again,
>
> On 26/04/2017 12:32, Paolo Carlini wrote:
>>
>> Hi,
>>
>> in 2013 (2013-09-16) Adam added two slightly obscure functions and I can't
>> find much around in terms of rationale, etc:
>>
>> /* Returns true iff TYPE is a TEMPLA
On 04/27/2017 02:02 PM, Paolo Carlini wrote:
... replying to myself, in practice we could do the below, which
certainly passes testing, and in fact now seems to me even more obvious
than I thought a couple of days ago...
I'm insufficiently conceptified to know whether this is safe (but lack
Hi again,
On 26/04/2017 12:32, Paolo Carlini wrote:
Hi,
in 2013 (2013-09-16) Adam added two slightly obscure functions and I
can't find much around in terms of rationale, etc:
/* Returns true iff TYPE is a TEMPLATE_TYPE_PARM representing 'auto',
'decltype(auto)' or a concept. */
bool
is
On Mon, 7 Sep 2015, Jonathan Wakely wrote:
> Nice, I think they are good improvements.
Cool. I committed this, only to notice another change.
GCC stands for GNU Compiler Collection, to GCC compiler would
expand to GNU Compiler Collection compiler, which feels a bit
redundant. ;-)
I'll wait a bi
On 7 September 2015 at 11:51, Gerald Pfeifer wrote:
> Jonathan,
>
> On Thu, 13 Aug 2015, Jonathan Wakely wrote:
>> Thanks, I've committed the attached change to the wwwdocs repo.
>
> looking at this I noticed a reference to "Subversion", when in
> general we have tried to minimize references to spe
Jonathan,
On Thu, 13 Aug 2015, Jonathan Wakely wrote:
> Thanks, I've committed the attached change to the wwwdocs repo.
looking at this I noticed a reference to "Subversion", when in
general we have tried to minimize references to specific version
control systems.
And I noticed we can be a littl
And a small correction.
On 13 August 2015 at 10:24, Jonathan Wakely wrote:
> Here's the patch for the rest of the C++17 support.
>
> On 13 August 2015 at 09:58, Jonathan Wakely wrote:
>> On 12 August 2015 at 23:54, Dijk, J. van wrote:
>>> Thanks for the clarification. I hope the attached patch
definitions >= 201411
+
+
+ Allow constant evaluation for all non-type template arguments
+ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4268.html";>N4268
+ No
+ __cpp_nontype_template_args >= 201411
+
+
+
C++ concepts
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4377.pdf";>N4377
- 6
+ 6
__cpp_concepts >= 201507
-r1.19 changes.html
--- htdocs/gcc-6/changes.html 31 Jul 2015 12:06:47 - 1.19
+++ htdocs/gcc-6/changes.html 13 Aug 2015 08:35:44 -
@@ -68,8 +68,33 @@
C++
The default mode has been changed to -std=gnu++14.
+C++ Concepts are now supported when compiling with
+-std=gn
> From: Jonathan Wakely [jwakely@gmail.com]
>Sent: 12 August 2015 17:41
>On 12 August 2015 at 16:20, Dijk, J. van wrote:
>> Dear all,
>>
>> Looking into gcc/cp/Changelog, it appears that on 2015-08-06 support
>> for the C++ Concepts TS was added to trunk.
>
Aug 7 00:41:30 2015 -0400
Add C++ Concepts TS support.
gcc/c-family/
* c-common.c (c_common_reswords): Add __is_same_as, concept, requires.
* c-common.h (enum rid): Add RID_IS_SAME_AS, RID_CONCEPT, RID_REQUIRES.
(D_CXX_CONCEPTS, D_CXX_CONCEPTS_FLAGS): N
Today is the first day I've had to look at these comments.
>>if (TEMPLATE_PARM_CONSTRAINTS (current_template_parms))
>> -TYPE_CANONICAL (type) = type;
>> +SET_TYPE_STRUCTURAL_EQUALITY (type);
>
>
> This seems like papering over an underlying issue. What was the testcase
> that motiva
> It looks like things are coming together pretty well. What's your feeling
> about readiness to merge into the trunk? Is the branch down to no
> regressions?
They are coming together pretty well. We have one major unit test
failure involving template introductions (Braden is working on it),
one
It looks like things are coming together pretty well. What's your
feeling about readiness to merge into the trunk? Is the branch down to
no regressions?
See you on Monday!
@@ -4146,21 +4146,21 @@ build_new_function_call (tree fn, vec
**args, bool koenig_p,
if (TREE_CODE (fn) == TEMP
A little bit of code went missing due to the constant expressions code
being factored out. Additionally, concepts are currently dependent on
changes to CPTK_IS_CONVERTIBLE_TO, so this patch restores that. I'm
told that this was removed from trunk and that the concepts branch will
be adapted t
This is a large patch mostly written by Andrew to change how constraints
are stored. It brings the implementation more in line with the
specification and simplifies some parts.
I'm not entirely sure about the change to
cp_parser_template_argument_list. What happens here is when a template
t
w
for every .exp file.
Using /home/faculty/asutton/local/share/dejagnu/baseboards/unix.exp as
board description file for target.
Using /home/faculty/asutton/local/share/dejagnu/config/unix.exp as
generic interface file for target.
Using
/home/faculty/asutton/Code/gcc/c++-concepts/gcc/testsuite/c
Fixing issues reported by users.
2014-10-20 Andrew Sutton
Fixing user-reported issues and regressions
* gcc/cp/parser.c (cp_parser_template_declaration_after_exp):
Only pop access checks on failed parsing.
* gcc/cp/pt.cpp (type_dependent_expr_p): Always treat a
-family/c.opt
@@ -924,7 +924,7 @@ C ObjC C++ ObjC++
Where shorter, use canonicalized paths to systems headers.
fconcepts
-C++ ObjC++ Var(flag_concepts, false)
+C++ ObjC++ Var(flag_concepts)
Enable support for C++ concepts
fcilkplus
The original patch for concept introductions was not popping a
deferred access check. This fixes that problem, although I'm not sure
if we need to defer access checks at all.
2014-10-13 Andrew Sutton
Fix regression related to concept introductions.
* gcc/cp/constraint.cc (cp_pa
And here's the patch:
Andrew Sutton
On Mon, Oct 13, 2014 at 3:33 PM, Andrew Sutton
wrote:
> Sometimes, cleanup_point_exprs are being added to concept definitions.
> This patch allows that to happen, but removes the cleanup point during
> normalization.
>
> 2014-10-13 Andrew Sutton
>
>
Sometimes, cleanup_point_exprs are being added to concept definitions.
This patch allows that to happen, but removes the cleanup point during
normalization.
2014-10-13 Andrew Sutton
Fix bug related to cleanup expressions in concept definitions.
* gcc/cp/constraint.cc (check_fun
Do not allow. Return type deduction only happens during instantiation,
and concepts are never instantiated. Therefore, we can't find the
return type of a function concept until you try to normalize the
return expression.
2014-09-25 Andrew Sutton
Explicitly disallow function concepts wi
On 2014-09-29 18:32, Jason Merrill wrote:
> On 09/29/2014 11:46 AM, Andrew Sutton wrote:
>> The main reason for the restriction is that concept definitions are
>> normalized into a single constraint-expression. And it's not obvious
>> how things like using declarations and static-assertions should
On 09/29/2014 11:46 AM, Andrew Sutton wrote:
The main reason for the restriction is that concept definitions are
normalized into a single constraint-expression. And it's not obvious
how things like using declarations and static-assertions should be
interpreted within the constraint language.
A
> Hmm, have we actually discussed this in core review? I'm not seeing it on
> the wiki. Constexpr started out this way too, and allowing static_assert
> was added pretty fast. C++11 said
>
> its function-body shall be = delete, = default, or a compound-statement that
> contains only
> — null sta
On 09/29/2014 10:55 AM, Andrew Sutton wrote:
Jason, do you want to review this before I commit? This is a pretty small patch.
No need to wait for review before committing to the branch.
+ // If fn was declared with auto, make sure the result type is bool.
+ if (FNDECL_USED_AUTO (fn) && TREE
This fixes an ICE trying to normalize a function concept with multiple
statements. That error will now be diagnosed at the point of
definition.
Jason, do you want to review this before I commit? This is a pretty small patch.
2014-09-01 Andrew Sutton
Check requirements on function conc
Adds support for concept introduction short hand.
Andrew already committed this patch.
2014-09-04 Braden Obrzut
* gcc/cp/constraint.cc (deduce_concept_introduction): New.
(build_concept_check): Allow arg to be NULL to skip placeholder.
(process_introduction_parm): New.
(f
Added tests for constrained friends. No code, we already to the right thing.
2014-08-15 Andrew Sutton
Add tests for constrained friends.
* gcc/testsuite/g++.dg/concepts/friend1.C: New.
* gcc/testsuite/g++.dg/concepts/friend2.C: New.
Andrew
Index: gcc/testsuite/g++.dg/concepts/friend2
Ah... thanks for the clarification. Fixed (and committed).
Andrew
On Thu, Aug 21, 2014 at 4:26 AM, Paolo Carlini wrote:
> Hi Andrew,
>
>
> On 08/20/2014 11:08 PM, Andrew Sutton wrote:
>>>
>>> On 08/20/2014 08:56 PM, Andrew Sutton wrote:
+ return VAR_P (decl)
+ && DECL_LAN
Hi Andrew,
On 08/20/2014 11:08 PM, Andrew Sutton wrote:
On 08/20/2014 08:56 PM, Andrew Sutton wrote:
+ return VAR_P (decl)
+ && DECL_LANG_SPECIFIC (decl)
+ && DECL_DECLARED_CONCEPT_P (decl);
this is brittle from the formatting point of view. Please double check in
detail what
Fixes a regression in lookup rules involving declarations with
nested-name-specifiers. In particular, we don't actually want to
execute these rules if we absolutely don't have to.
2014-08-15 Andrew Sutton
Fixing regression in scoping rules for templates.
* gcc/cp/semantics.c (fixup_tmeplat
> On 08/20/2014 08:56 PM, Andrew Sutton wrote:
>>
>> + return VAR_P (decl)
>> + && DECL_LANG_SPECIFIC (decl)
>> + && DECL_DECLARED_CONCEPT_P (decl);
>
> this is brittle from the formatting point of view. Please double check in
> detail what I'm going to say, but I think that in suc
Hi,
On 08/20/2014 08:56 PM, Andrew Sutton wrote:
+ return VAR_P (decl)
+ && DECL_LANG_SPECIFIC (decl)
+ && DECL_DECLARED_CONCEPT_P (decl);
this is brittle from the formatting point of view. Please double check
in detail what I'm going to say, but I think that in such cases you
Add more diagnostics for variable concepts. Also fix a regression
where non-template concepts variables were causing ICEs because they
aren't being allocated via build_lang_decl.
2014-08-15 Andrew Sutton
Additional declaration restrictions on variable concepts.
* gcc/cp/decl.c (is_concept_
This patch adds checks for user-defined logical operators during
constraint normalization and ensures that all atomics can be converted
to bool.
2014-08-14 Andrew Sutton
Implement normalization checks.
* gcc/cp/constraint.cc (normalize_expr): Delegate cast and
atomic no
The first improves support for shorthand concepts, and includes the
ability to write default arguments. Also, no more ICE when omitting
identifiers for template parameters.
The second adds constraint checks when taking the address of an
overloaded function.
Corresponding change logs follow:
2014
Just committed this patch, fixing the bootstrap.
2014-08-13 Andrew Sutton
Fix regression in bootstrap.
* gcc/cp/call.c (get_temploid): Removed. No longer called.
(joust): Remove unused variable declarations.
Andrew
On Wed, Aug 13, 2014 at 9:50 PM, Andrew Sutton
wrote:
> Ah... sorry. Le
Ah... sorry. Leftovers. I didn't have time to run a full bootstrap
build before heading out for a few days. I'll try to get those out
tomorrow afternoon-ish.
Andrew
On Wed, Aug 13, 2014 at 9:13 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> I get build fail:
>
> ../../gcc_concepts/gcc/cp/cal
I get build fail:
../../gcc_concepts/gcc/cp/call.c:8793:8: error: unused variable ‘m1’
[-Werror=unused-variable]
tree m1 = get_temploid (cand1);
^
../../gcc_concepts/gcc/cp/call.c:8794:8: error: unused variable ‘m2’
[-Werror=unused-variable]
tree m2 = get_temploid (cand2);
pec_args, orig_parms, list);
+ TREE_TYPE (list) = TREE_TYPE (t);
+}
}
}
Index: gcc/cp/call.c
===
--- gcc/cp/call.c (revision 213667)
+++ gcc/cp/call.c (working copy)
@@ -9010,14 +9010,10 @@ joust (struct
Committed.
Andrew Sutton
On Wed, Aug 13, 2014 at 3:24 AM, Braden Obrzut wrote:
> This patch adds support for variable concepts.
>
> There is a known issue that prevents concept variables from having requires
> expressions that have parameters. This issue is not within the scope of
> this patch
This patch adds support for variable concepts.
There is a known issue that prevents concept variables from having
requires expressions that have parameters. This issue is not within the
scope of this patch as it affects adhoc requires expressions as well.
2014-08-13 Braden Obrzut
* gc
Fixing some bugs substituting through constraints. In particular, when
diagnosing an error, make sure that we use the right arguments.
There was also a bug caused by substitution through a decltype-type.
In particular, when folding a non-dependent expression containing a
decltype-type, the inner t
This patch revisits the normalization and checking of constraints. In
particular, it ensures that associated constraints are always
normalized so that checking constraints will never instantiate a
concept declaration.
This also removes the constraint check from fn_type_unification as per
discussio
Rewrite the constraint-checking code so that it doesn't instantiate
concept definitions. Instead of doing a simple constexpr evaluation on
the associated constraints, this now iterates over the decomposed
assumptions to determine satisfaction.
2014-08-06 Andrew Sutton
* gcc/cp/constrain
Applied an updated version of this patch.
2014-7-30 Braden Obrzut
* gcc/cp/parser.c (cp_parser_trailing_requirements): Handle requires
keyword manually so that we can push function parameters back into
scope.
* gcc/cp/decl.c (push_function_parms): New. Recovers a
he partial ordering of function
+templates. add_function_candidate() will not have
+ counted the "this" argument for constructors. */
+ cand1->num_convs + DECL_CONSTRUCTOR_P (cand1->fn));
+ if (winner)
+return winner;
+}
+
+// C++ Conc
Fix a couple of issues causing a test regression and boostrap build errors.
2014-07-11 Andrew Sutton
* gcc/cp/typeck.c (cp_build_function_call_vec): Emit diagnostic
at the input location.
* gcc/cp/error.c (dump_template_decl): Constraints are never invalid
in thi
This patch restores C++98 as the default language in this branch and
disables -fconcepts by default. Using -std=c++1z will enable
-fconcepts.
I wanted to give an error if -fconcepts is used with dialect <= cxx11,
but I didn't find the right place to put the check.
This also adds a new format spec
After merging from trunk this morning, I discovered that
DECL_SIZE_UNIT is now being used to store lists of specializations. I
had been using that to store template constraints. Oops.
This patch moves constraints outside the usual tree structures into an
association maintained in a hash table. It
On 06/27/2014 09:41 AM, Ed Smith-Rowland wrote:
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason
to doubt that it will be done soon. The __cplusplus date is 201402L.
I guess we should set this correctl
On 06/26/2014 11:28 PM, Jason Merrill wrote:
On 06/26/2014 09:38 PM, Ed Smith-Rowland wrote:
So is C++14 a done deal with a __cplusplus date and all?
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason
t
> Please drop gcc/ and gcc/testsuite/ prefixes (the former goes to
> cp/ChangeLog, the latter to testsuite/ChangeLog).
This is the format (and file) that Gaby requested when we started the
project. We can certainly distribute the entries, but I don't know if
its worthwhile right now.
Andrew
On Fri, Jun 27, 2014 at 03:41:36AM -0400, Braden Obrzut wrote:
> On 06/27/2014 03:27 AM, Marek Polacek wrote:
> >Two spaces after you name.
> I'm not sure what happened to the second space. It's there in the source I
> copied. I'll have to be sure to double check the paste next time.
> >Please dr
Hi,
On 06/27/2014 09:41 AM, Braden Obrzut wrote:
Are you sure about this? Andrew has been putting everything in
ChangeLog.concepts in the root.
In terms of general GCC rules, Marek is certainly right. Whether Andrew
has (very) special reasons for doing that I don't know, meant to ask for
some
On 06/27/2014 03:27 AM, Marek Polacek wrote:
Two spaces after you name.
I'm not sure what happened to the second space. It's there in the
source I copied. I'll have to be sure to double check the paste next time.
Please drop gcc/ and gcc/testsuite/ prefixes (the former goes to
cp/ChangeLog, t
On Fri, Jun 27, 2014 at 03:22:39AM -0400, Braden Obrzut wrote:
> To bring the implementation in line with changes going into the concepts
> draft, use syntactical equivalence in place of logical equivalence when
> matching declarations.
>
> 2014-06-27 Braden Obrzut
Two spaces after you name.
>
To bring the implementation in line with changes going into the concepts
draft, use syntactical equivalence in place of logical equivalence when
matching declarations.
2014-06-27 Braden Obrzut
* gcc/cp/constraint.c (equivalent_constraints): Compare the trees
directly
instead of logic
On 06/26/2014 09:38 PM, Ed Smith-Rowland wrote:
So is C++14 a done deal with a __cplusplus date and all?
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason to
doubt that it will be done soon. The __cplu
So is C++14 a done deal with a __cplusplus date and all?
I've been waiting for some news or a trip report from Rapperswil and
have seen nothing on isocpp.
I've been thinking of adding a thing or two to C++1z like clang has -
The Disabling trigraph expansion by default looks easy.
Ed
On 06/26/2014 12:23 PM, Jason Merrill wrote:
We could add -std=c++1z and add it to that, though.
Added.
Jason
On 06/26/2014 11:15 AM, Ed Smith-Rowland wrote:
I, for one, would like gcc to bootstrap with c++11/c++14. I think we
should be starting to shake down that path. I'm probably not alone in
this.
Agreed.
On the other hand, I don't think c++-concepts branch should be the
leader on
down that path. I'm probably not alone in this.
On the other hand, I don't think c++-concepts branch should be the
leader on this. We have our work cut out for us without fighting these
bugs. Maybe a c++11-bootstrap branch could be started to work the c++1*
bootstrap out.
A
Updating constraint parsing to match changes to spec. Constraints must
always left unfolded, even when non-dependent, until they are
evaluated.
2014-06-25 Andrew Sutton
* gcc/cp/parser.c (cp_parser_requires_clause): Don't fold expressions
when parsing a requires-clause.
> I did a full 3-stage bootstrap which is the default these days.
> I'll try --disable-bootstrap and see what happens.
I just did a full bootstrap build and got the same errors. The errors
are correct for C++11, which was enabled by default in this branch.
IIRC, aggregate initialization requires t
On 06/24/14, Andrew Sutton wrote:
Weird. Any chance you're doing a bootstrap build?
There was an earlier bootstrapping issue with this branch. We had
turned on -std=c++1y by default, and it was causing some conversion
errors with lvalue references to bitfields in libasan.
This doesn't *look
Weird. Any chance you're doing a bootstrap build?
There was an earlier bootstrapping issue with this branch. We had
turned on -std=c++1y by default, and it was causing some conversion
errors with lvalue references to bitfields in libasan.
This doesn't *look* like a regression caused by concepts
I'm not sure the warning is correct in any case...
In i386.h
struct stringop_algs
{
const enum stringop_alg unknown_size;
const struct stringop_strategy {
const int max;
const enum stringop_alg alg;
int noalign;
} size [MAX_STRINGOP_ALGS];
};
in i386.c
---
I am still having problems doing a full build.
I get stuck on something that I think can't be a concepts problem in
gcc/config/i386/i386.c:
make[3]: Entering directory `/home/ed/obj_concepts/gcc'
/home/ed/obj_concepts/./prev-gcc/xg++
-B/home/ed/obj_concepts/./prev-gcc/
-B/home/ed/bin_concept
Actually allow member concepts in using shorthand notation.
2014-06-24 Andrew Sutton
* gcc/cp/parser.c (cp_maybe_constrained_type_specifier): Defer
handling the BASELINK check until concept-resolution in order to
allow member conceps.
(cp_parser_nonclass_name): A
This helps improve debug output. When pretty printing template args
including a placeholder, show instead of a dump_expr
error.
2014-06-24 Andrew Sutton
* gcc/cp/error.C (dump_expr): Pretty print placeholder to improve
debug output.
Committed as r211942.
Andrew
Index: gcc/cp/error.c
Committed as r211935. I updated the patch to add a more appropriate
comment and changelog entry.
Andrew
On Tue, Jun 24, 2014 at 8:07 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> I saw this during bootstrap. I've verified that the patch works (I was
> working on similar).
>
> Ed
>
Index: pa
I saw this during bootstrap. I've verified that the patch works (I was
working on similar).
Ed
Braden,
Did you have a specific test case that causes this breakage? I have a
feeling that if we're missing base-link nodes in one place, we'll miss
them in others too.
Andrew
On Tue, Jun 17, 2014 at 4:54 AM, Braden Obrzut wrote:
> cp_maybe_constrained_type_specifier asserted that the decl pas
This patch allows function parameters to be referenced by trailing
requires clauses. Typically this is used to refer to the type of an
implicitly generated template. For example, the following should now be
valid (where C is some previously defined concept):
auto f1 (auto x) requires C ();
cp_maybe_constrained_type_specifier asserted that the decl passed in
would be of type OVERLOAD, however a clean build of the compiler was
broken since it could also be a BASELINK. I'm not entirely sure when
this is the case, except that it seems to happen with class member
templates as it also
Sorry if you receive multiple versions of this. The original message
bounced (formatting).
Attached is a patch that greatly improves terse notation support for
generic functions and the use of concept names in
constrained-type-specifiers. There are actually 2 patches. The second
includes unit test
ed message --
From: Andrew Sutton
Date: Wed, Oct 16, 2013 at 9:59 AM
Subject: [c++-concepts] Shorthand notation
To: gcc-patches@gcc.gnu.org, Jason Merrill
I've committed initial support for shorthand constraints. This patch
adds support for parsing a concept-names as non-class names. Whe
Applying a patch from Ville that adds diagnostics for the concept
specifier. Thanks Ville!
2013-10-30 Ville Voutilainen
* gcc/cp/decl.c (grokdeclarator): Reject concept keyword
in typedefs, function parameters, data members, non-static
member functions and variables. All
Partially fixing a bug that caused lookup errors in valid programs. For example:
template
pair::type void f(T, U); // Error, no such pair
When entering a template scope, we tried to match the template to one
having the same constraints. Obviously pair doesn't have Int and Float
constraints, and
This patch prevents the use of requires expressions in non-template
scopes. This restriction was relaxed in the most recent version of
concepts lite, but the implementation requires some thought. For now,
I am marking it an error to make it consistent with previous versions
of the spec.
2013-10-25
rs that we grabbed for some other
>> concepts-related work, but which aren't included in Concepts Lite.
>>
>> I'll apply the typeck fix.
>>
>> Andrew Sutton
>>
>>
>> On Tue, Oct 22, 2013 at 10:02 PM, Ed Smith-Rowland <3dw...@verizon.net>
>
ouple of others that we grabbed for some other
concepts-related work, but which aren't included in Concepts Lite.
I'll apply the typeck fix.
Andrew Sutton
On Tue, Oct 22, 2013 at 10:02 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
I had to get past two small bugs to get c++
This patch disallows the explicit specialization of concepts, as
required by the specification. It also fixes an ICE when comparing
overloads of non-template members.
2013-10-23 Andrew Sutton
* gcc/cp/class.c (get_member_fntemplate): New.
(are_constrained_member_overloads): Only
oncepts-related work, but which aren't included in Concepts Lite.
I'll apply the typeck fix.
Andrew Sutton
On Tue, Oct 22, 2013 at 10:02 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> I had to get past two small bugs to get c++-concepts to build.
> Take a good look
I had to get past two small bugs to get c++-concepts to build.
Take a good look because I'm not sure if they're right. The solutions
should be harmless though.
Ed
2013-10-23 Edward Smith-Rowland <3dw...@verizon.net>
make concepts build.
* constraint.cc (
On 10/22/2013 08:54 AM, Andrew Sutton wrote:
This fixes the longstanding problem with bitfield references. The
default dialect was set to cxx1y, which was resulting different
conversions for bitfield references. I'm not sure if there's a change
in semantics for 1y or if that's a separate bug, but
1 - 100 of 283 matches
Mail list logo
