https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92593
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236
--- Comment #6 from Andrew Sutton ---
I'm going to send a patch for this, hopefully this morning, that ties concept
diagnostics into static asserts. It wasn't as bad as I thought it was going to
be.
I didn't implement this:
static_assert (!In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89442
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89913
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90287
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92078
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92040
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92186
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92103
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92403
--- Comment #2 from Andrew Sutton ---
This seems like a duplicate of 92186.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92214
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92403
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92439
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71125
--- Comment #3 from Andrew Sutton ---
The TS did allow overloading function concepts.
Function concepts have some parsing issues related to TS-style terse notation,
overloading and variadic templates. In particular, there are places where
writin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78752
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67862
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67860
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67825
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67774
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67727
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67719
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67704
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67697
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67692
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67685
--- Comment #3 from Andrew Sutton ---
Fixed in the concepts-cxx2a branch and added a test for the PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67684
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67658
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67654
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67427
--- Comment #1 from Andrew Sutton ---
I believe that the ambiguity is correct under the revised semantics of
concepts.
The targets of the parameter mapping in Sentinel differs for the two
declarations of distance because the order of template pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67319
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67225
--- Comment #7 from Andrew Sutton ---
It looks like there was an earlier state where access was being turned
off by one construct or another. All of the examples here fail as they're
supposed to. Added tests to concepts-cxx2a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67217
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67210
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67178
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147
--- Comment #6 from Andrew Sutton ---
There's a test for this PR in the concepts-cxx2a branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67148
--- Comment #3 from Andrew Sutton ---
This seems to have been fixed at some point. All examples compile in the
concepts-cxx2a branch, which also has a test for this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67147
--- Comment #5 from Andrew Sutton ---
This seems to have been fixed at some point. All examples compile in the
concepts-cxx2a branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
--- Comment #11 from Andrew Sutton ---
Most of the concerns in this issue have been resolved when concept satisfaction
was defined in terms of normalized constraints in all contexts (requirements or
otherwise). In particular. negation makes the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66844
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.n.sutton at gmail dot com
Target Milestone: ---
When a constrained-type-specifier is the same as that of a parameter type, the
return type is not deduced.
template concept bool C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71965
--- Comment #5 from Andrew Sutton ---
Hmm... I haven't looked at this in a while. It looks like the expansion of
ConstructibleObject is triggering the diagnostic. I'm a
little surprised that this gets diagnosed -- especially with a "sorry". But i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67685
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
--- Comment #8 from Andrew Sutton ---
And as an afterthought, adding negation makes the subsumption solver more
complex, since determining implications in the presence of negation would mean
decomposition of both the left and right sides of the i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
--- Comment #7 from Andrew Sutton ---
We haven't evaluated constraints as expressions in a long time (since
post-Rapperswil I think).
I don't think this is a good idea, but mostly because I'm not sure what the
instantiation/satisfaction semantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
--- Comment #2 from Andrew Sutton ---
> This is a very subtle point. It seems to me that it would be better if
> creating the normal form of a constaint stops substituting into concept bodies
> once it's clear that we're inside an atomic constra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962
--- Comment #14 from Andrew Sutton ---
Created attachment 36054
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36054&action=edit
Optimize constraint decomposition by contraction
The problem isn't strictly related to decomposition -- it's n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962
--- Comment #13 from Andrew Sutton ---
There are a couple of other problems in the minimized example (concept int
shows up a couple of times, there's a variable template whose initializer is a
requires expression). I doubt those contribute to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66988
--- Comment #1 from Andrew Sutton ---
I don't know if that's strictly a concepts issue. My guess is that the template
argument coersion of this argument:
template class
to this parameter:
template class
is not succeeding.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #12 from Andrew Sutton ---
> So it seems that applying the DR 1430 tentative resolution to concepts
> severely
> limits the usability of variadic concepts, and we should reconsider that, so
> that instead we delay normalization of te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66841
--- Comment #1 from Andrew Sutton ---
The program is ill-formed. In this line:
requires Constructible() // ERROR HERE
There's no single declaration of Constructible that can be matched to those
template arguments. You would need one with thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #7 from Andrew Sutton ---
> I would expect a partial ordering to prefer the two-parameter overload in that
> case. But yeah, it's a separate issue.
The problem is that partial ordering doesn't apply to template
parameters whose argum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834
--- Comment #2 from Andrew Sutton ---
I think that this is invalid too. There's an expansion from an
uninstantiated template argument pack into a pair of template
parameters.
I think the program must be ill-formed in this case. It's not possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66092
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66091
--- Comment #1 from Andrew Sutton ---
Confirmed. Fixed in r223061.
When a function declaration started with a non-function declarator, the
requires-clause wasn't being attached to the right declarator object so it
wasn't being added to the decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854
--- Comment #2 from Andrew Sutton ---
Confirmed. Parsing a type requirement that names an alias template was giving
back a declaration, which wasn't being instantiated correctly.
r222769 unwraps the type from the declaration and will correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848
--- Comment #4 from Andrew Sutton ---
> I think that is actually not so unfortunate. Statically asserting
> concept models has helped me find numerous issues in my own code.
> I'm glad to hear the proposal is being extended to cover this.
U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848
--- Comment #2 from Andrew Sutton ---
Here's the result of the latest commit (r222332) on my system. test.cpp is the
program in the bug report.
Command being timed: "~/opt/bin/g++ -std=c++1z -c test.cpp"
User time (seconds): 0.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848
--- Comment #1 from Andrew Sutton ---
This is caused by the use of a concept outside of a requires clause -- it's
still a bug though. The TS doesn't actually include wording that would allow
this program to be valid.
Unfortunately, the first thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65681
--- Comment #1 from Andrew Sutton ---
This is a good one. It is a regression, but it didn't have to do with the
resolution of partial specializations.
The substitution into requires-expressions was too eagerly doing full semantic
on analysis on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65635
--- Comment #1 from Andrew Sutton ---
Confirmed and fixed in r221857.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65636
--- Comment #2 from Andrew Sutton ---
Confirmed and with a tentative fix in r221856.
Certain type declarations occurring at namespace scope are not given C++
language extensions, so when we try to pass those through tsubst_decl, the
specializati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65636
--- Comment #1 from Andrew Sutton ---
Created attachment 35225
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35225&action=edit
Proposed solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65634
--- Comment #2 from Andrew Sutton ---
Confirmed and fixed 221854, but I'd like a maintainer to look at the attached
patch.
The bug was caused by asking for TYPE_NOTHROW_P on the function return type
instead of the function type. Strangely, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65634
--- Comment #1 from Andrew Sutton ---
Created attachment 35222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35222&action=edit
Proposed solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575
--- Comment #6 from Andrew Sutton ---
The requires-clause comes before the = default (the = xxx) is considered part
of the function definition. So:
void f() requires true = default;
As a side note, the production following the requires-claus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575
--- Comment #4 from Andrew Sutton ---
Apparently I do not understand declarators. The attached patch searches through
the declarator structure to filter out declarator structures to which a
requires-clause cannot be attached.
I updated the pr665
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575
--- Comment #3 from Andrew Sutton ---
Created attachment 35163
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35163&action=edit
Patch applied in r221733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575
--- Comment #1 from Andrew Sutton ---
Confirmed and resolved in r221695.
Removed the check for trailing requires-clauses on non-function declarators.
This should make the presence of a trailing-requires clause in a context where
it doesn't belo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65552
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65269
--- Comment #4 from Andrew Sutton ---
> Seems to me that return requires() as yet does not do "type requirement"
> as mentioned in n3701.pdf, pg 6
I needed to push the relevant changes to Origin, which I just did.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65269
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59361
Andrew Sutton changed:
What|Removed |Added
CC||andrew.n.sutton at gmail dot
com
75 matches
Mail list logo
