OK.
On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini wrote:
> Hi again,
>
> On 26/04/2017 12:32, Paolo Carlini wrote:
>>
>> Hi,
>>
>> in 2013 (2013-09-16) Adam added two slightly obscure functions and I can't
>> find much around in terms of rationale, etc:
>>
>> /* Returns true iff TYPE is a TEMPLA
On 04/27/2017 02:02 PM, Paolo Carlini wrote:
... replying to myself, in practice we could do the below, which
certainly passes testing, and in fact now seems to me even more obvious
than I thought a couple of days ago...
I'm insufficiently conceptified to know whether this is safe (but lack
Hi again,
On 26/04/2017 12:32, Paolo Carlini wrote:
Hi,
in 2013 (2013-09-16) Adam added two slightly obscure functions and I
can't find much around in terms of rationale, etc:
/* Returns true iff TYPE is a TEMPLATE_TYPE_PARM representing 'auto',
'decltype(auto)' or a concept. */
bool
is
On Mon, 7 Sep 2015, Jonathan Wakely wrote:
> Nice, I think they are good improvements.
Cool. I committed this, only to notice another change.
GCC stands for GNU Compiler Collection, to GCC compiler would
expand to GNU Compiler Collection compiler, which feels a bit
redundant. ;-)
I'll wait a bi
On 7 September 2015 at 11:51, Gerald Pfeifer wrote:
> Jonathan,
>
> On Thu, 13 Aug 2015, Jonathan Wakely wrote:
>> Thanks, I've committed the attached change to the wwwdocs repo.
>
> looking at this I noticed a reference to "Subversion", when in
> general we have tried to minimize references to spe
Jonathan,
On Thu, 13 Aug 2015, Jonathan Wakely wrote:
> Thanks, I've committed the attached change to the wwwdocs repo.
looking at this I noticed a reference to "Subversion", when in
general we have tried to minimize references to specific version
control systems.
And I noticed we can be a littl
And a small correction.
On 13 August 2015 at 10:24, Jonathan Wakely wrote:
> Here's the patch for the rest of the C++17 support.
>
> On 13 August 2015 at 09:58, Jonathan Wakely wrote:
>> On 12 August 2015 at 23:54, Dijk, J. van wrote:
>>> Thanks for the clarification. I hope the attached patch
Here's the patch for the rest of the C++17 support.
On 13 August 2015 at 09:58, Jonathan Wakely wrote:
> On 12 August 2015 at 23:54, Dijk, J. van wrote:
>> Thanks for the clarification. I hope the attached patch against current
>> wwwdocs will be of use (only the name of the feature test macro is
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 ch
> 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 t
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
And here's the patch:
Andrew Sutton
On Mon, Oct 13, 2014 at 3:33 PM, Andrew Sutton
wrote:
> Sometimes, cleanup_point_exprs are being added to concept definitions.
> This patch allows that to happen, but removes the cleanup point during
> normalization.
>
> 2014-10-13 Andrew Sutton
>
>
On 2014-09-29 18:32, Jason Merrill wrote:
> On 09/29/2014 11:46 AM, Andrew Sutton wrote:
>> The main reason for the restriction is that concept definitions are
>> normalized into a single constraint-expression. And it's not obvious
>> how things like using declarations and static-assertions should
On 09/29/2014 11:46 AM, Andrew Sutton wrote:
The main reason for the restriction is that concept definitions are
normalized into a single constraint-expression. And it's not obvious
how things like using declarations and static-assertions should be
interpreted within the constraint language.
A
> Hmm, have we actually discussed this in core review? I'm not seeing it on
> the wiki. Constexpr started out this way too, and allowing static_assert
> was added pretty fast. C++11 said
>
> its function-body shall be = delete, = default, or a compound-statement that
> contains only
> — null sta
On 09/29/2014 10:55 AM, Andrew Sutton wrote:
Jason, do you want to review this before I commit? This is a pretty small patch.
No need to wait for review before committing to the branch.
+ // If fn was declared with auto, make sure the result type is bool.
+ if (FNDECL_USED_AUTO (fn) && TREE
Ah... thanks for the clarification. Fixed (and committed).
Andrew
On Thu, Aug 21, 2014 at 4:26 AM, Paolo Carlini wrote:
> Hi Andrew,
>
>
> On 08/20/2014 11:08 PM, Andrew Sutton wrote:
>>>
>>> On 08/20/2014 08:56 PM, Andrew Sutton wrote:
+ return VAR_P (decl)
+ && DECL_LAN
Hi Andrew,
On 08/20/2014 11:08 PM, Andrew Sutton wrote:
On 08/20/2014 08:56 PM, Andrew Sutton wrote:
+ return VAR_P (decl)
+ && DECL_LANG_SPECIFIC (decl)
+ && DECL_DECLARED_CONCEPT_P (decl);
this is brittle from the formatting point of view. Please double check in
detail what
> On 08/20/2014 08:56 PM, Andrew Sutton wrote:
>>
>> + return VAR_P (decl)
>> + && DECL_LANG_SPECIFIC (decl)
>> + && DECL_DECLARED_CONCEPT_P (decl);
>
> this is brittle from the formatting point of view. Please double check in
> detail what I'm going to say, but I think that in suc
Hi,
On 08/20/2014 08:56 PM, Andrew Sutton wrote:
+ return VAR_P (decl)
+ && DECL_LANG_SPECIFIC (decl)
+ && DECL_DECLARED_CONCEPT_P (decl);
this is brittle from the formatting point of view. Please double check
in detail what I'm going to say, but I think that in such cases you
Just committed this patch, fixing the bootstrap.
2014-08-13 Andrew Sutton
Fix regression in bootstrap.
* gcc/cp/call.c (get_temploid): Removed. No longer called.
(joust): Remove unused variable declarations.
Andrew
On Wed, Aug 13, 2014 at 9:50 PM, Andrew Sutton
wrote:
> Ah... sorry. Le
Ah... sorry. Leftovers. I didn't have time to run a full bootstrap
build before heading out for a few days. I'll try to get those out
tomorrow afternoon-ish.
Andrew
On Wed, Aug 13, 2014 at 9:13 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> I get build fail:
>
> ../../gcc_concepts/gcc/cp/cal
I get build fail:
../../gcc_concepts/gcc/cp/call.c:8793:8: error: unused variable ‘m1’
[-Werror=unused-variable]
tree m1 = get_temploid (cand1);
^
../../gcc_concepts/gcc/cp/call.c:8794:8: error: unused variable ‘m2’
[-Werror=unused-variable]
tree m2 = get_temploid (cand2);
Committed.
Andrew Sutton
On Wed, Aug 13, 2014 at 3:24 AM, Braden Obrzut wrote:
> This patch adds support for variable concepts.
>
> There is a known issue that prevents concept variables from having requires
> expressions that have parameters. This issue is not within the scope of
> this patch
Applied an updated version of this patch.
2014-7-30 Braden Obrzut
* gcc/cp/parser.c (cp_parser_trailing_requirements): Handle requires
keyword manually so that we can push function parameters back into
scope.
* gcc/cp/decl.c (push_function_parms): New. Recovers a
On 06/27/2014 09:41 AM, Ed Smith-Rowland wrote:
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason
to doubt that it will be done soon. The __cplusplus date is 201402L.
I guess we should set this correctl
On 06/26/2014 11:28 PM, Jason Merrill wrote:
On 06/26/2014 09:38 PM, Ed Smith-Rowland wrote:
So is C++14 a done deal with a __cplusplus date and all?
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason
t
> Please drop gcc/ and gcc/testsuite/ prefixes (the former goes to
> cp/ChangeLog, the latter to testsuite/ChangeLog).
This is the format (and file) that Gaby requested when we started the
project. We can certainly distribute the entries, but I don't know if
its worthwhile right now.
Andrew
On Fri, Jun 27, 2014 at 03:41:36AM -0400, Braden Obrzut wrote:
> On 06/27/2014 03:27 AM, Marek Polacek wrote:
> >Two spaces after you name.
> I'm not sure what happened to the second space. It's there in the source I
> copied. I'll have to be sure to double check the paste next time.
> >Please dr
Hi,
On 06/27/2014 09:41 AM, Braden Obrzut wrote:
Are you sure about this? Andrew has been putting everything in
ChangeLog.concepts in the root.
In terms of general GCC rules, Marek is certainly right. Whether Andrew
has (very) special reasons for doing that I don't know, meant to ask for
some
On 06/27/2014 03:27 AM, Marek Polacek wrote:
Two spaces after you name.
I'm not sure what happened to the second space. It's there in the
source I copied. I'll have to be sure to double check the paste next time.
Please drop gcc/ and gcc/testsuite/ prefixes (the former goes to
cp/ChangeLog, t
On Fri, Jun 27, 2014 at 03:22:39AM -0400, Braden Obrzut wrote:
> To bring the implementation in line with changes going into the concepts
> draft, use syntactical equivalence in place of logical equivalence when
> matching declarations.
>
> 2014-06-27 Braden Obrzut
Two spaces after you name.
>
On 06/26/2014 09:38 PM, Ed Smith-Rowland wrote:
So is C++14 a done deal with a __cplusplus date and all?
The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason to
doubt that it will be done soon. The __cplu
So is C++14 a done deal with a __cplusplus date and all?
I've been waiting for some news or a trip report from Rapperswil and
have seen nothing on isocpp.
I've been thinking of adding a thing or two to C++1z like clang has -
The Disabling trigraph expansion by default looks easy.
Ed
On 06/26/2014 12:23 PM, Jason Merrill wrote:
We could add -std=c++1z and add it to that, though.
Added.
Jason
On 06/26/2014 11:15 AM, Ed Smith-Rowland wrote:
I, for one, would like gcc to bootstrap with c++11/c++14. I think we
should be starting to shake down that path. I'm probably not alone in
this.
Agreed.
On the other hand, I don't think c++-concepts branch should be the
leader on this. We hav
On 06/25/2014 10:03 AM, Andrew Sutton wrote:
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
> I did a full 3-stage bootstrap which is the default these days.
> I'll try --disable-bootstrap and see what happens.
I just did a full bootstrap build and got the same errors. The errors
are correct for C++11, which was enabled by default in this branch.
IIRC, aggregate initialization requires t
On 06/24/14, Andrew Sutton wrote:
Weird. Any chance you're doing a bootstrap build?
There was an earlier bootstrapping issue with this branch. We had
turned on -std=c++1y by default, and it was causing some conversion
errors with lvalue references to bitfields in libasan.
This doesn't *look
Weird. Any chance you're doing a bootstrap build?
There was an earlier bootstrapping issue with this branch. We had
turned on -std=c++1y by default, and it was causing some conversion
errors with lvalue references to bitfields in libasan.
This doesn't *look* like a regression caused by concepts
I'm not sure the warning is correct in any case...
In i386.h
struct stringop_algs
{
const enum stringop_alg unknown_size;
const struct stringop_strategy {
const int max;
const enum stringop_alg alg;
int noalign;
} size [MAX_STRINGOP_ALGS];
};
in i386.c
---
I am still having problems doing a full build.
I get stuck on something that I think can't be a concepts problem in
gcc/config/i386/i386.c:
make[3]: Entering directory `/home/ed/obj_concepts/gcc'
/home/ed/obj_concepts/./prev-gcc/xg++
-B/home/ed/obj_concepts/./prev-gcc/
-B/home/ed/bin_concept
Committed as r211935. I updated the patch to add a more appropriate
comment and changelog entry.
Andrew
On Tue, Jun 24, 2014 at 8:07 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> I saw this during bootstrap. I've verified that the patch works (I was
> working on similar).
>
> Ed
>
Index: pa
I saw this during bootstrap. I've verified that the patch works (I was
working on similar).
Ed
Braden,
Did you have a specific test case that causes this breakage? I have a
feeling that if we're missing base-link nodes in one place, we'll miss
them in others too.
Andrew
On Tue, Jun 17, 2014 at 4:54 AM, Braden Obrzut wrote:
> cp_maybe_constrained_type_specifier asserted that the decl pas
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 "assume",
"axiom
On 10/23/2013 08:36 AM, Andrew Sutton wrote:
Hi Ed,
It looks like we did reserve "assume" as a keyword, but it's not being
used... By any chance, did you configure without --disable-bootstrap?
I think it would be a better solution to remove the unused keywords --
there were a couple of others t
Hi Ed,
It looks like we did reserve "assume" as a keyword, but it's not being
used... By any chance, did you configure without --disable-bootstrap?
I think it would be a better solution to remove the unused keywords --
there were a couple of others that we grabbed for some other
concepts-related
On 10/22/2013 08:54 AM, Andrew Sutton wrote:
This fixes the longstanding problem with bitfield references. The
default dialect was set to cxx1y, which was resulting different
conversions for bitfield references. I'm not sure if there's a change
in semantics for 1y or if that's a separate bug, but
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 Sutton wrote:
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
* gcc/cp/constraint.cc (finish_concept_name): Allow functions with
the same name as concepts to r
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
usual way.
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,
> will that still
OK.
If we have a friend declaration inside a constrained partial
specialization, will that still get a false positive?
Jason
Hi Andrew,
On 10/04/2013 07:36 PM, Andrew Sutton wrote:
+ if (!check_template_constraints (tmpl, args))
+{
+ location_t loc = DECL_SOURCE_LOCATION (function);
+ error ("%qD is not a viable candidate", function);
+ diagnose_constraints (
OK.
Jason
>>> >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
On 10/04/2013 09:20 AM, Andrew Sutton wrote:
>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 bel
>> + // 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.
>
>
>
On 10/02/2013 09:05 AM, Andrew Sutton wrote:
+ // 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-templat
On 09/21/2013 08:52 AM, Andrew Sutton wrote:
It is wrong, but not for the reasons I gave. This only happens when
you try to constrain a friend function that declares a specialization,
which happens to be completely separate from the previously declared
template.
I'm going to disallow the abili
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
On 09/13/2013 12:21 PM, Andrew Sutton wrote:
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 friend declarations whose constraints are not satisfied
("no matching t
Will amend and commit tomorrow morning!
Andrew
Andrew Sutton
On Tue, Sep 10, 2013 at 7:54 PM, Gabriel Dos Reis wrote:
> Andrew Sutton writes:
>
> | I added a new macro to replace the use of TREE_TYPE to get
> | constraints. It's called TEMPLATE_PARMS_CONSTRAINTS. Patch attached:
> |
> | 2013-0
Andrew Sutton writes:
| 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
| * gcc/cp/cp-tree.h (TEMPLATE_PARMS_CONSTRAINTS): New.
| * gcc/cp/parser.c (cp_parser_template_declar
Andrew Sutton writes:
| The last merge didn't compile for me. Apparently some pretty printing
| functions have disappeared that were being called in the concept
| stuff. This patch just replaces the broken calls to pp_cxx_type_id
| with pp->type_id.
|
| Ok to commit?
yes, please. Sorry for tha
Andrew Sutton writes:
| Ok to commit? Attached is the doc fix patch. I'll send the TREE_TYPE
| patch shortly.
Yes, please -- that is what Jason earlier. Let me know when youve
committed so that I can synchronize with trunk.
-- Gaby
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 wrote:
> On 09/06/2013 12:03 PM, Andrew Sutton wrote:
>>
>> +// Returns the template type of the class scope being entered. If we're
>> +// ente
On 09/06/2013 12:03 PM, Andrew Sutton wrote:
+// Returns the template type of the class scope being entered. If we're
+// entering a constrained class scope. TMPL is the most general template
+// of the scope being entered, and TYPE is its type.
TMPL is not part of the interface of fixup_templa
Updated as per comments.
I moved the resolve_template_scope function out to
finish_template_type. I couldn't figure out how to get the parsed
template parameter from the looked-up template in
lookup_class_template. That information may not be available outside
the parse state.
Andrew
Andrew Sutto
On 09/04/2013 01:33 PM, Andrew Sutton wrote:
Ah. The goal is to check after we've deduced/coerced template
arguments into a valid substitution. With functions, that's in
fn_type_unification (hopefully called from instantiate_template)
Actually fn_type_unification calls instantiate_template, but
>> It's not supposed to be different. Checking constraints in
>> instantiate_template is actually too late. We want to check before
>> instantiation, at the point of use.
>
> Right, what I was getting at is that instantiate_template actually only
> instantiates the declaration of a function, not th
On 09/04/2013 11:59 AM, Andrew Sutton wrote:
It's not supposed to be different. Checking constraints in
instantiate_template is actually too late. We want to check before
instantiation, at the point of use.
Right, what I was getting at is that instantiate_template actually only
instantiates th
>> 1. Type constraints are checked on lookup rather than instantiation.
>
>
> How is this different from function template constraints? Is this just a
> difference in internal function name (instantiate_template vs
> lookup_template_class)?
It's not supposed to be different. Checking constraints
On 09/03/2013 11:01 AM, Andrew Sutton wrote:
Attached is a patch for constrained class templates. It's the 3rd time
I've sent it.
Please feel free to ping me if you're waiting for a patch review; once a
week is not too much.
1. Type constraints are checked on lookup rather than instantiatio
Looks good.
Jason
Tom Tromey writes:
| > "Gaby" == Gabriel Dos Reis writes:
|
| Gaby> We will have to watch out for Tom's Makefile rewrite work.
|
| FWIW, I've found rebasing this series to be very easy.
| Due to the way it is split up, only one patch (the big manual dependency
| removal one) only ever has
> "Gaby" == Gabriel Dos Reis writes:
Gaby> We will have to watch out for Tom's Makefile rewrite work.
FWIW, I've found rebasing this series to be very easy.
Due to the way it is split up, only one patch (the big manual dependency
removal one) only ever has "hard" conflicts, and that patch is
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 declarations like regular
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 declarations like regular PARM_DECL references
| and gives errors that they are unexpanded packs.
|
| 201
Makes sense.
Jason
> 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
Hi,
On 07/26/2013 03:23 PM, Andrew Sutton wrote:
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 t
> 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
Hi,
On 07/26/2013 02:11 PM, Andrew Sutton wrote:
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.
Isn't the name a little misleading? I immediately wondered what was
wrong with
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/c
On 07/25/2013 10:19 AM, Andrew Sutton wrote:
+ pp_cxx_parameter_declaration_clause(pp, TREE_OPERAND (t, 0));
Space before (. Otherwise, looks good.
Jason
On 07/13/2013 05:37 AM, Andrew Sutton wrote:
There are two instantiations on purpose.
OK.
A lot of the new code in pt.c doesn't seem like it needs to be there; let's
put as much in constraint.cc as we can. Let's move some of the bits out of
semantics.c as well.
I think the [fixup|declare]_
> 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)
On 07/11/2013 02:59 PM, Andrew Sutton wrote:
pp_cxx_requirement_parameter_list (cxx_pretty_printer *pp, tree t)
This should be merged with pp_cxx_parameter_declaration_clause.
+reqparms_to_string (tree p)
And this should have a more generic name.
+ // requries clause.
"requires"
+
On 07/10/2013 08:24 AM, Andrew Sutton wrote:
That's a good idea. I changed every existing use of can_convert to
can_convert_standard for the time being. That will preserve the
existing behavior, and we can determine which of the existing uses can
include user-defined conversions later.
Let's le
>> 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
On 07/04/2013 11:30 AM, Andrew Sutton wrote:
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
>> 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
On 07/01/2013 01:27 PM, Andrew Sutton wrote:
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, tha
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
> 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
>> 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
On 06/27/2013 04:56 PM, Andrew Sutton wrote:
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 const
1 - 100 of 190 matches
Mail list logo
