Re: contracts library support (was Re: [PATCH] PING implement pre-c++20 contracts)

> Is just using std::terminate as the handler viable? Or if we're sure > contracts in some form will go into the IS eventually, and the > signature won't change, we could just add it in __cxxabiv1:: as you > suggested earlier. No, the handler needs to be configurable (at least quietly) in order

Re: [PATCH] PING implement pre-c++20 contracts

I think so, yes. On Fri, Jul 2, 2021 at 11:09 AM Jason Merrill wrote: > > On 7/1/21 12:27 PM, Andrew Sutton wrote: > >>> I think this version addresses most of your concerns. > >> > >> Thanks, looking good. I'll fuss with it a bit and commit it soon. > &

Re: [PATCH] PING implement pre-c++20 contracts

> > I think this version addresses most of your concerns. > > Thanks, looking good. I'll fuss with it a bit and commit it soon. Awesome! Andrew

Re: [PATCH] implement pre-c++20 contracts

> > > > Attached is a new squashed revision of the patch sans ChangeLogs. The > > current work is now being done on github: > > https://github.com/lock3/gcc/tree/contracts-jac-alt > > I'm starting to review this now, sorry for the delay. Is this still the > branch you want me to consider for GCC

Re: [PATCH] implement pre-c++20 contracts

Hi Jason, Sorry I haven't been able to get back to this. I've been swamped with other work, and we haven't had the resources to properly address this. Jeff Chapman will be working on cleaning this up for when master/trunk re-opens. > I find the proposed always_continue semantics kind of

[PATCH] PR C++/92739

Find attached. gcc/cp/ * parser.c (cp_parser_constraint_requires_parens): Exclude attributes as postfix expressions. gcc/testsuite/ * g++.dg/concepts-pr92739.C: New test. Andrew Sutton 0001-Fix-PR-c-92739.patch Description: Binary data

Re: [PATCH] Prevent recursive satisfaction (PR c++/88395)

> > + if (tmpl) > > + push_tinst_level (tmpl); > > Actually, why not pass 't' here? I thought it would matter if 't' was a non-template. Turns out it doesn't. Updated and committed.

[PATCH] PR c++/92439: Improve diagnostics for ill-formed requires-clauses

This does a much better job identifying when an expression in a requires-clause needs parentheses. Andrew Sutton 0001-PR-c-92439.patch Description: Binary data

[PATCH] PR c++/92236: Improve static assertions of concepts

expression ‘* i’ is invalid 8 | *i; | ^~ Andrew Sutton 0001-Emit-detailed-diagnostics-for-static-assertion-failu.patch Description: Binary data

Re: [PATCH] Prevent recursive satisfaction (PR c++/88395)

sn't crash, but it doesn't diagnose also doesn't fail as a result of recursive instantiation. The recursive-sat2.C test is the same except that it instantiates foo with a class type. This seems like it might be related to ADL, but entirely certain. Andrew Sutton On Mon, Nov 18, 2019 at 10:13 AM Andrew Sut

[PATCH] Prevent recursive satisfaction (PR c++/88395)

This applies on top of the patch here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html Wrap satisfaction with push/pop_tinst_level to force termination on recursion. Andrew Sutton 0001-Prevent-recursive-satisfaction-PR-c-88395.patch Description: Binary data

[PATCH] Fixes PR c++/89913

Avoid ICE when the alias is ill-formed. gcc/cp/ * pt.c (get_underlying_template): Exit loop if the original type of the alias is null. gcc/testsuite/ * g++.dg/cpp2a/pr89913.C: New test. Andrew Sutton 0001-Don-t-segfault-on-error-PR-c-89913.patch Description: Binary data

[PATCH] PR c++/92078 Add access specifiers to specializations

Fixes mentioned issue. Tested on bootstrap and cmcsstl2. gcc/cp/ * pt.c (maybe_new_partial_specialization): Apply access to newly created partial specializations. Update comment style. gcc/testsuite/ * g++.dg/cpp2a/concepts-pr92078.C: New. Andrew pr92078.patch Description: Binary data

[PATCH] PR c++/92403

with a concept (either before or after the patch), you get false. So, this seems like the right behavior. Andrew Sutton 0001-Suppress-diagnostics-substituting-into-a-requires-ex.patch Description: Binary data

[PATCH] Diagnose hard errors during constraint satisfaction

. This patch also fixes the crash PR92439, which was caused by not building the normalization tree in satisfy_constraint_expression. However, there are some other problems with that example that cause it to not compile (e.g., non-boolean atomic constraints). Andrew Sutton 0001-Diagnose-certain-constraint

Re: [PATCH] fix constrained auto parsing issue

In cp_parser_simple_type_specifier: if (!type && flag_concepts && decl_specs) { /* Try for a type-constraint with template arguments. We check decl_specs here to avoid trying this for a functional cast. */ ... It's subtle. Andrew Sutton On Mon, Oct 21, 2019

[PATCH] fix constrained auto parsing issue

This fixes a parsing bug with constrained placeholders uses as the first parameter of a constructor. Andrew Sutton 0001-Fix-a-bug-with-type-constraints-in-constructors.patch Description: Binary data

[PATCH] diagnose hard errors in concept satisfaction

don't build that information until we know we need to diagnose an error. This patch does not include that context. Andrew Sutton errors.patch Description: Binary data

[PATCH] concepts cleanups and subsumption caching

, but it will prevent redundant and potentially costly comparisons of constraints. Tested on bootstrap and vs. cmcstl2. Andrew Sutton cleanup.patch Description: Binary data

Re: [C++ Patch] PR 71140 ("[concepts] ill-formed nested-requirement lacking a semicolon not rejected")

Sorry for the slow reply. I've been stuck working on some other projects. > Can you say a bit about why that was better than continuing to use > VAR_DECL? > I wanted to make sure that we avoid normal VAR_DECL processing routines, so we don't e.g., slip into a function where we might try to

Re: [concepts] Update to match the working draft (and bit more)

id I wasn't able to deliver your message to the following addresses. >> This is a permanent error; I've given up. Sorry it didn't work out. >> >> : >> ezmlm-reject: fatal: Sorry, I don't accept messages larger than 40 bytes (#5.2.3) > Andrew Sutton

Re: [C++ Patch] PR 71140 ("[concepts] ill-formed nested-requirement lacking a semicolon not rejected")

> > BTW, I would discourage you from messing much with the concepts code > at this point, as a major overhaul should be coming soon. > Major overhaul: https://github.com/asutton/gcc (branch is concepts; we're about 2 weeks back from trunk). Unfortunately, I we haven't been following GCC commit

Re: [PATCH] Add -std=c++2a

). I was going to submit a followup that emits a warning when both -std=c++2a and -fconcepts are both enabled and then disables -fconcepts. Andrew Sutton On Thu, Jul 20, 2017 at 1:04 PM, Markus Trippelsdorf <mar...@trippelsdorf.de> wrote: > On 2017.07.20 at 09:33 -0400, Andrew Sut

[PATCH] Add -std=c++2a

. gcc/testsuite/ New test for -std=c++2a. * g++.dg/cpp2a/cplusplus.C: New. Andrew Sutton cxx2a.patch Description: Binary data

Re: [PATCH] Giant concepts patch

Ah sure. Jason has been vetting my post-Jacksonville concepts patch in the branch jason/concepts-rewrite. I just pulled this off the github GCC mirror this morning to look at an outstanding question. Resulted in the previous 2 patches. I tried building a fresh pull of your cmcstl2 and got an

Re: [PATCH] Giant concepts patch

. You're missing a const overload of operator* for basic_operator. Patch forthcoming. Changelogs below. 2016-07-10 Andrew Sutton <andrew.n.sut...@gmail.com> * constraint.cc (tsubst_type_constr, tsubst_implicit_conversion_constr, tsubst_argument_deduction_

Re: C++ PATCH for non-type constrained-type-specifiers

> I started looking at allowing non-type constrained-type-specifiers in auto > deduction and then realized that we didn't handle them in function > parameters either. Fixing that brought home to me the oddity of having a > type-specifier stand in for a non-type. Mind weighing in on that on the >

Re: C++ PATCH to implement fold-expressions

Fantastic. I've wanted to get back to this, but since school started back up, I haven't had any time to look at it. Thanks! Andrew On Thu, Sep 17, 2015 at 2:04 PM, Jason Merrill wrote: > Back in January Andrew mostly implemented C++1z fold-expressions >

concept diagnostics

This is not a proper patch. I'm missing the usual changelog and I'm still running the regression tests, but I wanted to get some opinions before committing more time to it. This patch extends the diagnostics for concepts to report precise failures when constraints are not satisfied. It currently

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

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

Re: Concepts code review

+// Bring the parameters of a function declaration back into +// scope without entering the function body. The declarator +// must be a function declarator. The caller is responsible +// for calling finish_scope. +void +push_function_parms (cp_declarator *declarator) I think if the caller

[c++-concepts] merge from trunk

I just merged the concepts branch with trunk, after fighting with the testing framework for the past hour. There was a change to gcc/testsuite/lib/prune.exp yesterday that doesn't appear to be compatible with *something* in this branch. It broke the entire test suite, giving the errors below for

Re: Concepts code review

+ // The constraint info maintains information about constraints + // associated with the declaration. + tree constraint_info; We talked back at the end of June about moving this into a separate hashtable; I'm still reluctant to add another pointer to most declarations when only a

Re: Concepts code review

Agreed. I'll probably start looking at this on Friday morning. Note that end of stage 1 is Saturday, as I just realized today. So the sooner the better. :) Ouch. Good thing my merge with trunk broke in unexpected ways this morning -- minimally, something in cgraph ended up missing a

[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] 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. * gcc

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

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] 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: gcc

[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

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. * gcc/cp

[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

: 2014-08-13 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/class.c (resolve_address_of_overloaded_function): Check constraints. * gcc/cp/decl.c (grokfndecl): For now, disallow constrained non-template functions. * gcc/testsuite/g++.dg/concepts: New tests

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

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

Re: Patch for constexpr variable templates

Oohh... I can commit to trunk? Yes, you're on the write-after-approval list in MAINTAINERS. :) True, but it's my first commit to trunk :) Incidentally, that's committed now. Andrew

[c++-concepts] explicit instantiation and specialization

constraints. * gcc/cp/decl.c (various) Cosmetic fixes. (adjust_fn_constraints): Rewrite so that class template constraints are not imposed on member function declarations. * gcc/testsuite/g++.dg/concepts: New tests. Andrew Sutton Index: gcc/cp/decl.c

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:

Re: Patch for constexpr variable templates

* pt.c (lookup_template_variable): Make the type unspecified if any template arguments are dependent. This hunk is OK. Hi Jason, did you apply this hunk of the patch, or should I just resend this by itself? Andrew

Re: Patch for constexpr variable templates

Oohh... I can commit to trunk? I can do it tomorrow morning. Andrew Sutton On Tue, Aug 12, 2014 at 4:59 PM, Jason Merrill ja...@redhat.com wrote: On 08/12/2014 04:21 PM, Andrew Sutton wrote: * pt.c (lookup_template_variable): Make the type unspecified if any template

[c++-concepts] substitution fixes

type is not being resolved (because tsubst returns early when args == NULL_TREE). The second patch fixes a regression introduced by the first patch. 2014-08-11 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/pt.c (tsubst): Don't short circuit substitution into types when

Re: Patch for constexpr variable templates

* decl.c (cp_finish_decl): Don't check the initializer if it is value-dependent. Why is this needed? I thought that check_initializer was evaluating the constant expression, and was resulting in errors because a template-id referring to a variable template with a concrete

[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

(push_function_parms): New. Recovers and reopens function parameter scope from declarator. * gcc/testsuite/g++.dg/concepts/req*.C: New tests. 2014-07-30 Andrew Sutton andrew.n.sut...@gmail.com * gcc/testsuite/g++.dg/concepts/test.C: Removed. Andrew Sutton On Tue, Jun 17, 2014 at 5:06

Re: Patch for constexpr variable templates

It sounds like GCC's behavior with auto in function parameters needs to be changed, but that definitely sounds like a separate patch to me. I think so. It's definitely a different patch. Agreed. I've been thinking about a simple way for your patch to add to the constraints for

[c++-concepts] overloading update

be overloaded by type. They are not ordered by their constraints. This patch also contains an uncommitted change fixing some small diagnostic issues. Unfortunately, they got lumped together. 2014-07-28 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/cp-tree.h (more_constraints): Remove

Re: Patch for constexpr variable templates

In the 59638 case, the declarations void (*a)(auto); void (*b)(auto) = 0; are shorthand for template typename T void (*a)(T); template typename T void (*b)(T) = 0; which, unless there's some constraint with variable templates that I'm not aware of, ought to define two variable

Re: Patch for constexpr variable templates

But someday we'll want non-constexpr too. I have only seen a sentence somewhere stating that non-constexpr variable templates are allowed but have seen no paper or wording anywhere. Does anyone know where such exists? When variable templates were proposed, EWG decided they wanted

[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

[c++-concepts] constraint association

. It also lays the framework for allowing constraints to be associated with any _*DECL node (templates, functions, variables, types, etc). Changelog below; committed as 212103. 2014-06-28 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/cp-tree.h (DECL_CONSTRAINTS): Remove this macro; use

[c++-concepts] Compiler options/bootstrap

specifier (Z) to the cxxdiag flags. That warning was turning into an error in the bootstrap build. FYI: The bootstrap builds cleanly for me now. Committed in r212105. 2014-06-28 Andrew Sutton andrew.n.sut...@gmail.com * gcc/c-family/c.opt (flag_concepts): Don't enable by default

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

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

[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 don't think I'm touching the initializer code at all. Andrew Sutton On Tue, Jun 24, 2014 at 11:42 AM, Ed Smith-Rowland 3dw...@verizon.net wrote: I'm not sure the warning is correct in any case... In i386.h struct stringop_algs { const enum stringop_alg unknown_size

terse notation diagnostics

Adds additional checks and tests for ill-formed programs. 2014-06-12 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/parser.c (cp_check_type_concept): New. (cp_check_concept_name): Remove redundant condition from check. Diagnose misuse of non-type concepts

partial-concept-ids

Add support for partial concept ids. Mostly this just refactors the basic support for concept names to also allow a template and extra arguments. Also added the missing .exp file for the test suite. 2014-06-12 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/constraint.cc

[c++-concepts] Terse notation

-specifiers in compound requirements: {expr} - const auto; // unnamed result type must form a valid type {expr} - C; // unnamed result type satisfies the concept C Semantics will come later. Changelog: 2014-06-11 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/cp-tree.h

Re: [PATCH] [C++ RFC] Support named type capture for generic lambdas and generic functions as proposed by N3878

It's not clear that this feature will be part of concepts. It will not be included in the initial working paper, so the proposal will need to be re-evaluated. Andrew On Tue, Mar 25, 2014 at 3:03 AM, Adam Butcher a...@jessamine.co.uk wrote: * parser.c (cp_parser_simple_type_specifier):

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

S { void f(); } templateInt T void ST::f() { } // Should be an error The right solution seems to be to diagnose the error only when defining an out-of-class member by verifying that each template scope in the qualified name matches a declaration with the same constraints. 2013-10-30 Andrew

[c++-concepts] Diagnostics patch

functions and variables. Allow static member functions to be concepts. Andrew Sutton Index: gcc/cp/decl.c === --- gcc/cp/decl.c (revision 204092) +++ gcc/cp/decl.c (working copy) @@ -9074,6 +9074,12 @@ if (name == NULL

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

-25 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/parsre.c (cp_parser_requires_expression): Gracefully fail when parsing a requires expr outside a template. Andrew Sutton template-requires.patch Description: Binary data

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

Hi Ed, I committed half of your patch (the unused variable part) in r204011 and removed the unused keywords as a resolution for the other half in r204012. Changelog/patch follow: 2013-10-24 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/c-common.c (c_common_r): Remove unused

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

[c++-concepts] bitfield reference bugfix

an ICE for invalid constrained friends. 2013-10-16 Andrew Sutton andrew.n.sut...@gmail.com * gcc/c-family/c-common.c (cxx_dialect): Make the default language C++11. * gcc/cp/constraint.cc (check_constrained_friend): Don't assert on error_mark_node. Andrew bugfix

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

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

[c++-concepts] Shorthand notation

the current implementation is a bit hacky, and I'm wondering if I should introduce a new node for a pack conjunction. Change log follows. 2013-10-16 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/constraint.cc (conjoin_requiremens): New. (resolve_constraint_check): Filter non-concept

Re: [c++-concepts] friends regression

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

[c++-concepts] friends regression

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

Re: [c++-concepts] constrained friends redux

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

Re: [c++-concepts] constrained friends redux

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?

[c++-concepts] constrained friends redux

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

Re: [c++-concepts] Constrained friends

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

[c++-concepts] Constrained friends

for the specialization. And then we only check the constraints if the declaration is a non-friend. 2013-09-13 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/cp-tree.h (check_constrained_friend): New. * gcc/cp/pt.c (determine_specialization): Only check constraints after

[c++-concepts] template parameter constraints

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

Re: [c++-concepts] template parameter constraints

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

Re: [c++-concepts] Class template constraints

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

  1   2   >