> And you need to do this even when the call is type-dependent?
Yes. Especially when the call is type-dependent. That's how I generate
the constraint sets, which are used to determine the most constrained
template during overload resolution.
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
> 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
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 con
>> 2. I left the include in system.h, because removing it will
>> result in errors due to an inclusion of . It's probable
>> that both can be removed, but I didn't test it with this patch.
>
>
> You mean you don't need anymore in logic.cc? I think we want
> the include in general if we're going
>> +// If the types of the underlying templates match, compare
>> +// their constraints. The declarations could differ there.
>> +if (types_match)
>> + types_match = equivalent_constraints (get_constraints
>> (olddecl),
>> +
at point I will do the merge from trunk. We don't want to
> have the branch too old compared to the trunk.
>
> -- Gaby
--
Andrew Sutton
andrew.n.sut...@gmail.com
site?
How will this change the workflow? What's the process for submitting
changes using git?
Andrew
On Thu, Jun 20, 2013 at 8:57 AM, Jason Merrill wrote:
> On 06/20/2013 09:18 AM, Andrew Sutton wrote:
>>
>> I'll also create a github version of this branch, so can avoid
> The c++-concepts SVN branch won't come in with a clone; you need to add it
> to the fetch list with
>
> git config --add remote.origin.fetch
> refs/remotes/c++-concepts:refs/remotes/origin/c++-concepts
>
> Then you can check out a local branch based on it.
Already did that. I probably need to do
>
>
> The one caveat is that git-svn historically hasn't handled merges very well.
> I think git-svn v1.8.3 or newer can do the right thing, but I haven't tested
> it, so it's probably best to keep doing merges with the svn client for the
> time being.
>
> Jason
>
--
Andrew Sutton
andrew.n.sut...@gmail.com
reasonable number of error messages). But I
think the general algorithm is essentially the right approach. I did
this differently in an early version, and it was much more cumbersome.
Changes are pushed in git branch asutton/c++-concepts. The Changelog is below:
2013-06-20 Andrew Sutton
* gcc
Shoot. Forgot to attach the patch...
Andrew
On Fri, Jun 21, 2013 at 10:17 AM, Gabriel Dos Reis wrote:
> Andrew Sutton writes:
>
> | Changes are pushed in git branch asutton/c++-concepts. The Changelog
> | is below
>
> Andrew, please can you send me a diff? When reading em
Attached is the stubbed out parsing for requires expressions. I plan
on implementing semantics next.
I haven't pushed this into a git branch since its a completely
separate change from the previous patch. Should I create a new branch
for separate work?
Changelog:
2013-06-21 Andrew S
> | + // Concept extensions
> | + case RID_REQUIRES:
> | +return cp_parser_requires_expression (parser);
> | +
>
> I think you meant here "nested requirements", not "extensions" as in
> "GNU extensions" or "vendor lock-ins". We should continue with "nested
> requirements" then.
This denotes
tree expr =
cp_parser_binary_expression (parser, false, false, PREC_NOT_OPERATOR, NULL);
if (!require_potential_rvalue_constant_expression (expr))
return error_mark_node;
return expr;
}
Okay to commit?
On Sat, Jun 22, 2013 at 9:41 AM, Gabriel Dos Reis wrote:
> Andrew S
probably incomplete. I think I may also need to propagate
constraints from constrained non-template constructors as well.
Changelog:
2013-06-22 Andrew Sutton
* gcc/cp/cp-tree.h (tree_template_info). Remove constraint from
template info.
(check_template_info): Removed (unused
t it where both
TEMPLATE_DECL and FUNCTION_DECL would have constraints.
On Sat, Jun 22, 2013 at 11:41 AM, Gabriel Dos Reis
wrote:
> On Sat, Jun 22, 2013 at 10:57 AM, Andrew Sutton
> wrote:
>> I changed the implementation to associate constraints with template
>> decls (ac
> Internally, we want to always store the canonical form of a decl, not the
> source-level form -- the current g++ AST isn't prepared for that (I wish
> it was, but it isn't.) This allows for simple comparison and other
> semantics processing.
Agreed. But without some source-level annotations in
> | Agreed. But without some source-level annotations in the tree, I don't
> | think I can generate the diagnostics that programmer's might otherwise
> | expect. I'd have to emit the internal representation.
>
> Do you have examples where we don't do or we can't do the obvious thing
> in terms of d
> | Previous discussion seemed to indicate that saving constraints with
> | template decls was preferable.
>
> Yes; exactly.
>
> | The committed version in the branch carries those constraints in
> | template_info for the temploid.
>
> Yes; I think that is good.
So we should associate constraints
> | But, I don't think we have a single TEMPLATE_PARM_DECL node. Template
> | parameters are either TYPE_DECLs or PARM_DECLs. I think auto
> | declarations, get VAR_DECLs, but I haven't looked closely at that
> | design. I'd have to look to see if there are any free tree slots all
> | of those decl
ve
whether or not an instantiated declaration actually satisfies its
requirements.
Andrew
On Sat, Jun 22, 2013 at 6:43 PM, Gabriel Dos Reis wrote:
> Andrew Sutton writes:
>
> | > | But, I don't think we have a single TEMPLATE_PARM_DECL node. Template
> | > | parameters are ei
__is_convertible_to since
expression requirements include conversion requirements.
This patch does not include instantiation or decomposition rules. I
wanted to get the design reviewed before implementing the more
intricate stuff.
Changelog:
2013-06-24 Andrew Sutton
* gcc/cp/cxx-pretty
on't correctly match S
against specializations (if any exist), nor will it match f, if f is
declared as a member function template. I'll address this after some
changes to class templates.
Changelog:
2013-06-24 Andrew Sutton
* gcc/cp/parser.c (cp_parser_init_declarator):
iated specializations.
Previously, this was allowed:
vector* p;
Assuming that vector restricted its arguments to only object types.
The program is ill-formed if vector is ever instantiated. This
patch causes formation of the type vector to result in an error.
Changelog:
2013-06-25 Andrew S
> Judging from the implementation, it seems that this relies on the notion of
> "potentially-constant expression" which is no longer part of the standard;
> that notion should only be used for diagnostics that are not required, not
> for things that participate in the type system.
>
> I think it wo
>> I was not aware of that. That's probably the right, but I remember
>> having some troubles getting that to work the way I wanted in the
>> previous implementation. It seemed like I actually had to evaluate the
>> expression to determine if it was actually constexpr.
>
>
> Right; an expression is
> This seems to assume that there is a result-type-requirement.
>
>> +// Returns true if type1 can be implicitly converted to type2.
>> +static inline bool
>> +convertible_to_p (tree type1, tree type2)
>> +{
>> + // Build a "fake" conversion expression to force the lookup of user
>> + // defined
Updated with corrections for previous comments. New patch attached,
but the Changelog is essentially the same.
>> +/* A unary expression representing a requirement for an expression that
>> + can be evaluated at compile time. */
>
> Judging from the implementation, it seems that this relies on
>> Unfortunately, the behavior differs from the test suite for
>> std::is_convertible. In particular, this fails:
>>
>> static_assert(__is_convertible_to(int(int), int(&)(int)), "");
>>
>> whereas this succeeds )
>>
>> static_assert(is_convertible::value, "");
>
>
> Hmm, that probably has to do w
>> I ran through every test in the is_convertible unit test with
>> __is_convertible. There are 2 cases it doesn't address. The conversion
>> of a function type (int()) to its reference type (int(&)()),
>
>
> I looked into this a bit more; it seemed odd to consider any conversion from
> int() since
The attached patch finishes the semantics for requires expressions. It
includes reduction rules for constraint decomposition, substitution
rules, and diagnostics.
Andrew
Changelog:
2013-07-11 Andrew Sutton
* gcc/cp/cp-tree.h (declare_local_parms): New
* gcc/cp/cp-tree.h
> This should be merged with pp_cxx_parameter_declaration_clause.
>
>> +reqparms_to_string (tree p)
>
>
> And this should have a more generic name.
I called this parms_to_string for symmetry with args_to_string. It
calls pp_cxx_parameter_declaration_clause.
>> + if (check_requirements (t, args)
Fixed and committed, but I have a small follow-up related to parameter
packs in requires clauses. The checking for unexpanded parameter packs
treats the parameter declarations like regular PARM_DECL references
and gives errors that they are unexpanded packs.
2013-07-26 Andrew Sutton
* gcc
This patch implements a new trait __is_same_as. This is foundational
for future work on concepts in that it provides a mechanism for
reasoning about type equivalences.
It also provides the correct preconditions for __is_convertible_to as
required in meta.rel.
2013-07-26 Andrew Sutton
> Isn't the name a little misleading? I immediately wondered what was wrong
> with std::is_same. IMHO something a little longer/technical clarifying that
> the trait isn't just about comparing types is in order...
Sure.
First, it means we don't have to instantiate any class templates in
order to
> Thanks a lot. Now I'm afraid that some of these nice clarifications,
> delicate technical details included, may get lost. Do you think they exist
> already in some of your design documents, papers, etc. Then a reference in
> the code would do. Otherwise, please consider adding some of the above t
Committed.
On Fri, Jul 26, 2013 at 10:27 PM, Gabriel Dos Reis wrote:
> Andrew Sutton writes:
>
> | Fixed and committed, but I have a small follow-up related to parameter
> | packs in requires clauses. The checking for unexpanded parameter packs
> | treats the parameter declaratio
specialization is added.
Change Log:
2013-08-02 Andrew Sutton
* gcc/cp/pt.c (get_class_bindings): Pass the partial specialization
for constraint evaluation. Evaluate constraints, resulting in
deduction failure on error.
(get_specializaing_template_decl
Reserving a handful of new keywords for concepts and several new type
traits in preparation for future work on concepts.
Andrew
2013-02-05 Andrew Sutton
* c-common.h (rid): New resreserved words for concepts.
* c-common.c (c_common_reswords): Definitions thereof
Of course. I'll send that along shortly.
Andrew
On Thu, Feb 28, 2013 at 8:51 AM, Gabriel Dos Reis
wrote:
> On Thu, Feb 28, 2013 at 8:07 AM, Andrew Sutton
> wrote:
>> Reserving a handful of new keywords for concepts and several new type
>> traits in preparation for
Attached is the initial documentation for the previous patch.
Andrew
2013-02-28 Andrew Sutton
* doc/extend.texi (write_symbol): Initial concept docs.
On Thu, Feb 28, 2013 at 9:11 AM, Gabriel Dos Reis
wrote:
> On Thu, Feb 28, 2013 at 9:01 AM, Andrew Sutton
> wrote:
>&g
constraints is stubbed out for the time being.
The flags patch just enables -fconcepts by default.
The combined change log is:
2013-03-01 Andrew Sutton
* cp-tree.h (saved_scope): Add template requirements.
(finish_template_requirements): Declare
* parser.c
the file as constraint.cc, but the build system in
this version doesn't seem to have to build support for .cc files (kept
getting "no such file: cp/constraint.o", but adding the file as .c
worked just fine.
2013-03-11 Andrew Sutton
* gcc/cp/Make-lang.in: Add constraint.c
Implements reduction of requirements into the constraints language:
logical formulas comprised of atomic propositions. Calls to constraint
predicates are recursively inlined in the resulting expression. All
other calls are treated as atoms.
2013-03-01 Andrew Sutton
* gcc/cp
non-template member functions.
2013-04-03 Andrew Sutton
* gcc/cp/cp-tree.def (CONSTRAINT_INFO): New node
* gcc/cp/cp-tree.h (require): New
(tree_constraint_info): New node type
(constraint_info_p): New
(cp_tree_node_structure_enum): New value
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
> 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
non-conste
> In the 59638 case, the declarations
>
> void (*a)(auto);
> void (*b)(auto) = 0;
>
> are shorthand for
>
> template void (*a)(T);
> template void (*b)(T) = 0;
>
> which, unless there's some constraint with variable templates that I'm not
> aware of, ought to define two 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 fo
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
* gcc/cp/cp-tree.h (more_constraints): Remove
and reopens
function parameter scope from declarator.
* gcc/testsuite/g++.dg/concepts/req*.C: New tests.
2014-07-30 Andrew Sutton
* gcc/testsuite/g++.dg/concepts/test.C: Removed.
Andrew Sutton
On Tue, Jun 17, 2014 at 5:06 AM, Braden Obrzut wrote:
> This patch all
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
* g
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
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 wrote:
> * parser.c (cp_parser_simple_type_specifier): Lookahead for a brac
Adding myself as Write After Approval maintainer.
Andrew Sutton
andrew.n.sut...@gmail.com
Index: ChangeLog
===
--- ChangeLog (revision 196207)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-02-20 Andrew Sutton
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.
&
> 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
to
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 nonsensi
>
>
> > 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 11
> > 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
101 - 161 of 161 matches
Mail list logo
