[pushed] c++: concepts TS and explicit specialization [PR101098]

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

c++: Concepts and local externs

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

[PATCH 7/7] C++ concepts: fix ICE with requires on dtors (PR c++/89036)

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:

Re: PING^2 Re: [PATCH v2] C++ concepts: fix ICE with requires on dtors (PR c++/89036)

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

PING^2 Re: [PATCH v2] C++ concepts: fix ICE with requires on dtors (PR c++/89036)

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

PING Re: [PATCH v2] C++ concepts: fix ICE with requires on dtors (PR c++/89036)

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

[PATCH v2] C++ concepts: fix ICE with requires on dtors (PR c++/89036)

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 ||

Re: [PATCH] C++ concepts: fix ICE with requires on dtors (PR c++/89036)

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

[PATCH] C++ concepts: fix ICE with requires on dtors (PR c++/89036)

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:

Re: [C++ Patch] Remove is_auto_or_concept, etc (Was: Re: [C++, concepts] Two slightly obscure pt.c functions?)

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: >> >> /*

Re: [C++ Patch] Remove is_auto_or_concept, etc (Was: Re: [C++, concepts] Two slightly obscure pt.c functions?)

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

[C++ Patch] Remove is_auto_or_concept, etc (Was: Re: [C++, concepts] Two slightly obscure pt.c functions?)

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

Re: [wwwdocs] Re: C++ Concepts available in trunk?

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

Re: [wwwdocs] Re: C++ Concepts available in trunk?

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

Re: [wwwdocs] Re: C++ Concepts available in trunk?

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

[wwwdocs] Re: C++ Concepts available in trunk?

On 12 August 2015 at 23:54, Dijk, J. van wrote: Thanks for the clarification. I hope the attached patch against current wwwdocs will be of use (only the name of the feature test macro is missing in the new file cxx1z.html; did not manage to find that.) Thanks, I've committed the attached

Re: [wwwdocs] Re: C++ Concepts available in trunk?

Here's the patch for the rest of the C++17 support. On 13 August 2015 at 09:58, Jonathan Wakely jwakely@gmail.com wrote: On 12 August 2015 at 23:54, Dijk, J. van wrote: Thanks for the clarification. I hope the attached patch against current wwwdocs will be of use (only the name of the

Re: [wwwdocs] Re: C++ Concepts available in trunk?

And a small correction. On 13 August 2015 at 10:24, Jonathan Wakely jwakely@gmail.com wrote: Here's the patch for the rest of the C++17 support. On 13 August 2015 at 09:58, Jonathan Wakely jwakely@gmail.com wrote: On 12 August 2015 at 23:54, Dijk, J. van wrote: Thanks for the

RE: C++ Concepts available in trunk?

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. Have Concepts in gcc matured to the point

Huge C++ PATCH to merge c++-concepts branch

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): New

Re: [c++-concepts] code review

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 motivated this

[c++-concepts] code review

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, vectree, va_gc **args, bool koenig_p, if (TREE_CODE

Re: [c++-concepts] code review

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

[c++-concepts] Restore missing code from previous trunk merge

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

[c++-concepts] Bring constraints in line with spec

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

[c++-concepts] merge from trunk

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/config

[c++-concepts]

Fixing issues reported by users. 2014-10-20 Andrew Sutton andrew.n.sut...@gmail.com 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

[c++-concepts] Fix inversion of -fconcepts

-family/c.opt +++ b/gcc/c-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

[c++-concepts] cleanup expressions

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 andrew.n.sut...@gmail.com Fix bug related to cleanup expressions in concept definitions. *

Re: [c++-concepts] cleanup expressions

And here's the patch: Andrew Sutton On Mon, Oct 13, 2014 at 3:33 PM, Andrew Sutton andrew.n.sut...@gmail.com 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

[c++-concepts] introduction syntax regression

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 andrew.n.sut...@gmail.com Fix regression related to concept introductions. *

[c++-concepts] function concepts with deduced return type

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 andrew.n.sut...@gmail.com Explicitly

[c++-concepts] Check function concept definitions

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 andrew.n.sut...@gmail.com Check

Re: [c++-concepts] Check function concept definitions

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)

Re: [c++-concepts] Check function concept definitions

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

Re: [c++-concepts] Check function concept definitions

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

Re: [c++-concepts] Check function concept definitions

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 be

[c++-concepts] concept introductions

Adds support for concept introduction short hand. Andrew already committed this patch. 2014-09-04 Braden Obrzut ad...@maniacsvault.net * gcc/cp/constraint.cc (deduce_concept_introduction): New. (build_concept_check): Allow arg to be NULL to skip placeholder.

Re: [c++-concepts] variable concept fixes

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 I'm

Re: [c++-concepts] variable concept fixes

Ah... thanks for the clarification. Fixed (and committed). Andrew On Thu, Aug 21, 2014 at 4:26 AM, Paolo Carlini paolo.carl...@oracle.com 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) +

[c++-concepts] constrained friends

Added tests for constrained friends. No code, we already to the right thing. 2014-08-15 Andrew Sutton andrew.n.sut...@gmail.com Add tests for constrained friends. * gcc/testsuite/g++.dg/concepts/friend1.C: New. * gcc/testsuite/g++.dg/concepts/friend2.C: New. Andrew Index:

[c++-concepts] variable concept fixes

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 andrew.n.sut...@gmail.com Additional declaration restrictions on variable concepts. *

Re: [c++-concepts] variable concept fixes

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

Re: [c++-concepts] variable concept fixes

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

[c++-concepts] template scoping error

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 andrew.n.sut...@gmail.com Fixing regression in scoping rules for templates. *

[c++-concepts] normalization checks

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 andrew.n.sut...@gmail.com Implement normalization checks. * gcc/cp/constraint.cc (normalize_expr): Delegate

[c++-concepts] 2 patches

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:

Re: [c++-concepts] explicit instantiation and specialization

Just committed this patch, fixing the bootstrap. 2014-08-13 Andrew Sutton andrew.n.sut...@gmail.com 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

[c++-concepts] variable concepts

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

Re: [c++-concepts] variable concepts

Committed. Andrew Sutton On Wed, Aug 13, 2014 at 3:24 AM, Braden Obrzut ad...@maniacsvault.net 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

[c++-concepts] explicit instantiation and specialization

(revision 213667) +++ gcc/cp/call.c (working copy) @@ -9010,14 +9010,10 @@ joust (struct z_candidate *cand1, struct } // C++ Concepts -// or, if not that, -// F1 and F2 are member functions of a class template specialization -// T, and M1 and M2 are member functions in the template

Re: [c++-concepts] explicit instantiation and specialization

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);

Re: [c++-concepts] explicit instantiation and specialization

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:

[c++-concepts] substitution fixes

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

[c++-concepts]

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 andrew.n.sut...@gmail.com

Re: [c++-concepts] Allow function parameters to be referenced in trailing requires clauses

Applied an updated version of this patch. 2014-7-30 Braden Obrzut ad...@maniacsvault.net * 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

[c++-concepts] overloading update

. */ + cand1-num_convs + DECL_CONSTRUCTOR_P (cand1-fn)); + if (winner) +return winner; +} + +// C++ Concepts +// or, if not that, +// F1 and F2 are member functions of a class template specialization +// T, and M1 and M2 are member functions in the template of T

[c++-concepts] fixes

Fix a couple of issues causing a test regression and boostrap build errors. 2014-07-11 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/typeck.c (cp_build_function_call_vec): Emit diagnostic at the input location. * gcc/cp/error.c (dump_template_decl): Constraints are

[c++-concepts] constraint association

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

[c++-concepts] Compiler options/bootstrap

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

[c++-concepts] Change constraint equivalence

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 ad...@maniacsvault.net * gcc/cp/constraint.c (equivalent_constraints): Compare the trees

Re: [c++-concepts] Change constraint equivalence

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 ad...@maniacsvault.net Two spaces

Re: [c++-concepts] Change constraint equivalence

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

Re: [c++-concepts] Change constraint equivalence

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 drop

Re: [c++-concepts] Change constraint equivalence

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

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

. 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. As long as gcc defaults

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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 this. We

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

On 06/26/2014 12:23 PM, Jason Merrill wrote: We could add -std=c++1z and add it to that, though. Added. Jason

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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

Re: Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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 ad...@maniacsvault.net wrote: cp_maybe_constrained_type_specifier

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

I saw this during bootstrap. I've verified that the patch works (I was working on similar). Ed

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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: parser.c

[c++-concepts] small pretty printing fix

This helps improve debug output. When pretty printing template args including a placeholder, show placeholder instead of a dump_expr error. 2014-06-24 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/error.C (dump_expr): Pretty print placeholder to improve debug output. Committed as

[c++-concepts] member concepts

Actually allow member concepts in using shorthand notation. 2014-06-24 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/parser.c (cp_maybe_constrained_type_specifier): Defer handling the BASELINK check until concept-resolution in order to allow member conceps.

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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/

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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 ---

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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

Re: Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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

[c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

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

[c++-concepts] Allow function parameters to be referenced in trailing requires clauses

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++-concepts] Terse notation

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

Fwd: [c++-concepts] Shorthand notation

-- From: Andrew Sutton andrew.n.sut...@gmail.com Date: Wed, Oct 16, 2013 at 9:59 AM Subject: [c++-concepts] Shorthand notation To: gcc-patches@gcc.gnu.org, Jason Merrill ja...@redhat.com I've committed initial support for shorthand constraints. This patch adds support for parsing a concept-names

[c++-concepts] Constrained scope bugfix

Partially fixing a bug that caused lookup errors in valid programs. For example: templateInt T, Float U pairT, U::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

[c++-concepts] Diagnostics patch

Applying a patch from Ville that adds diagnostics for the concept specifier. Thanks Ville! 2013-10-30 Ville Voutilainen ville.voutilai...@gmail.com * gcc/cp/decl.c (grokdeclarator): Reject concept keyword in typedefs, function parameters, data members, non-static member

[c++-concepts] Requires expr in non-templte

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.

Re: [c++-concepts] small tidbits to get it to build

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 because I'm not sure if they're right. The solutions should be harmless though. Ed I did

Re: [c++-concepts] small tidbits to get it to build

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 because I'm not sure if they're right

[c++-concepts] Specialization of concepts

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 andrew.n.sut...@gmail.com * gcc/cp/class.c (get_member_fntemplate): New.

Re: [c++-concepts] small tidbits to get it to build

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++-concepts to build. Take a good look

[c++-concepts] bitfield reference bugfix

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 it's not related to concepts. Also prevent

Re: [c++-concepts] bitfield reference bugfix

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,

[c++-concepts] small tidbits to get it to build

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 (make_constraints

Re: [c++-concepts] Shorthand notation

A small follow up change. This removes the sorry from concept name resolution. Committed in r203815. 2013-10-16 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/constraint.cc (finish_concept_name): Allow functions with the same name as concepts to resolve as call expressions in

Re: [c++-concepts] Shorthand notation

Hi, On 10/18/2013 02:23 PM, Andrew Sutton wrote: A small follow up change. This removes the sorry from concept name resolution. Committed in r203815. 2013-10-16 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/constraint.cc (finish_concept_name): Allow functions with the

Re: [c++-concepts] Shorthand notation

I know. When I started working on the project, Gaby asked that I keep all concept-related changes in the top-level Changelog.concepts with full paths for the file names. Andrew Sutton On Fri, Oct 18, 2013 at 8:53 AM, Paolo Carlini paolo.carl...@oracle.com wrote: Hi, On 10/18/2013 02:23 PM,

[c++-concepts] Bugfix

Fixing 2 issues. A test for __is_convertible_to was missing in diagnose_trait, and *somehow* the logic for determining constraint ordering w.r.t. requires expressions was missing. Committed in 203826. 2013-10-16 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/logic.cc (left_requires),

  1   2   3   >