> 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
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.
&
> > 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
>
>
> > 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
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
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
> > + 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.
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
expression ‘* i’ is invalid
8 | *i;
| ^~
Andrew Sutton
0001-Emit-detailed-diagnostics-for-static-assertion-failu.patch
Description: Binary data
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:1
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
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
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
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 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
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,
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
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
will prevent redundant and potentially costly
comparisons of constraints.
Tested on bootstrap and vs. cmcstl2.
Andrew Sutton
cleanup.patch
Description: Binary data
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 gener
the qmail-send program at sourceware.org.
>> I'm afraid 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
>
> 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 d
ation introducer (WD).
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
wrote:
> On 2017.07.20 at 09:33 -0400, Andrew Sutton wrote:
>>
.
gcc/testsuite/
New test for -std=c++2a.
* g++.dg/cpp2a/cplusplus.C: New.
Andrew Sutton
cxx2a.patch
Description: Binary data
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 off-b
s why Casey is
added to the mailing. You're missing a const overload of operator* for
basic_operator. Patch forthcoming.
Changelogs below.
2016-07-10 Andrew Sutton
* constraint.cc (tsubst_type_constr, tsubst_implicit_conversion_constr,
tsubst_argument_deducti
> 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
>
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
> (https://isocpp.org/files/papers/n4295.h
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 r
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
>>> +// 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
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
>> 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 #
>> + // 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 on
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
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/constrai
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-
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
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
> 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
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
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
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:
&
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/s
> 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
&g
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/d
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
:
2014-08-13 Andrew Sutton
* 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.
2014-08-13 Andrew Sutton
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... so
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
* 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
>> 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
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 sco
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 wrote:
> On 08/12/2014 04:21 PM, Andrew Sutton wrote:
>>>>
>>>> * pt.c (lookup_template_variable): Make the type unspecified
>>
>> * 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
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
* gcc/cp/pt.c (tsubst): Don't short circuit substitution into
types when processing constr
match the
wording the specification. Basically, "requirements -> constraints".
Updated all affected tests.
2014-08-08 Andrew Sutton
* gcc/cp/logic.cc (subsumes_constraints_nonnull): Don't re-normalize
constraints, it's already been done.
* gcc/cp/cp-
>> * 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 conc
This patch prevents the initializer from being checked when it is
dependent. It also sets the type of a dependent template-id referring
to a variable template to be unknown, making such expressions type
dependent.
2014-08-07 Andrew Sutton
* pt.c (lookup_template_variable): Make the
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
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
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
>> 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
> 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
> 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
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
w format 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
* gcc/c-family/c.opt (flag_concepts): Don't enable by default.
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
* gcc/cp/cp-tree.h (DECL_CONSTRAINTS): Remove this macro; use
get_constraints
> 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
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-c
> 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
y concepts -- 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
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
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
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
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
* gcc/cp/constraint.cc (deduce_constrained_parameter
Adds additional checks and tests for ill-formed programs.
2014-06-12 Andrew Sutton
* gcc/cp/parser.c (cp_check_type_concept): New.
(cp_check_concept_name): Remove redundant condition from check.
Diagnose misuse of non-type concepts in constrained type specifiers
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
* gcc/cp/cp-tree.h (build_constrained_parameter): R
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
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
. 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)
name = decl_context
template
void S::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 Sutton
* gcc/cp/s
-25 Andrew Sutton
* 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
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
* gcc/cp/c-common.c (c_common_r): Remove unused keywords "a
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
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
cepts.
Also prevent an ICE for invalid constrained friends.
2013-10-16 Andrew Sutton
* 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
b
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
* gcc/cp/logic.cc (left_requires), (decompose_left): Add
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 wrote:
> Hi,
>
>
> On 10/18/2013 02:23 PM, Andrew
A small follow up change. This removes the "sorry" from concept name
resolution. Committed in r203815.
2013-10-16 Andrew Sutton
* gcc/cp/constraint.cc (finish_concept_name): Allow functions with
the same name as concepts to resolve as call expressions in the
he 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
* gcc/cp/constraint.cc (conjoin_requiremens): New.
(resolve_constraint_check): Filter non-concept candidates bef
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 wrote:
> OK.
>
> If we have a friend declaration inside a constrained partial specialization,
&g
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
* gcc/cp/cp-tree.h (check_constrained_friend): Take requirements as
an argument.
* gcc/cp/constrain
>>> >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 mor
>> + // 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.
>
>
>
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
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
>> constr
he
best template for the specialization. And then we only check the
constraints if the declaration is a non-friend.
2013-09-13 Andrew Sutton
* gcc/cp/cp-tree.h (check_constrained_friend): New.
* gcc/cp/pt.c (determine_specialization): Only check constraints
after determinin
1 - 100 of 161 matches
Mail list logo
