[Bug c++/116095] satisfaction of atomic constraint depends on itself, when piping boost range into range-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116095 --- Comment #1 from Enrico Maria De Angelis --- Forgot to say that at the question on stackoverflow I've listed other ways that make the code compile: - change list to vector - make r const
[Bug c++/116095] New: satisfaction of atomic constraint depends on itself, when piping boost range into range-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116095
Bug ID: 116095
Summary: satisfaction of atomic constraint depends on itself,
when piping boost range into range-v3
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: enricomaria.dean6elis at gmail dot com
Target Milestone: ---
Here's a simple example that fails to compile with GCC if -std=c++20 is passed.
It compiles with -std=c++17 with GCC. It compiles in both cases with Clang.
#include
#include
#include
#include
#include
#include
using namespace ranges;
using namespace ranges::views;
int main()
{
std::list v;
auto r = boost::make_iterator_range(v);
auto w = r
| transform([](auto x){ return x; })
| to_vector;
}
Initially, I had tried to squeeze the example a bit more, and got to the
following:
#include
#include
#include
int main() {
std::list l;
using Foo = const
ranges::ref_view>&;
ranges::_size_::has_non_member_size;
}
for which GCC <= 10.5 would compile.
I haven't received any useful reply/comment on stackoverflow
(https://stackoverflow.com/questions/78699349/why-gcc-11-1-rejects-range-v3-c20-concept-applied-to-ref-view-of-boostiterat),
nor or range-v3 github repo
(https://github.com/ericniebler/range-v3/issues/1823).
Here's a compiler explorer example: https://godbolt.org/
More info is at the stackoverflow question I linked.
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
--- Comment #7 from Enrico Maria De Angelis ---
(In reply to Arsen Arsenović from comment #6)
> is it possible to implement any correct terminating coroutine within those
> restrictions?
Is it a requirement that a coroutine must be terminate-able? I mean, if a
coroutine has neither of those two functions, but it's never resumed after a
suspension via co_await, what's the problem?
Take for instance a generator coroutine,
std::generator foo() {
int i{};
while (true) {
co_yield i++;
}
}
it will never terminate, so why should it have return_value or return_void?
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #5 from Enrico Maria De Angelis --- I've asked some feeback here https://stackoverflow.com/questions/75891694/is-it-legal-for-a-coroutines-promise-type-to-lack-both-return-void-and-return-v
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #4 from Enrico Maria De Angelis --- The more I read the standard, specifically http://eel.is/c++draft/dcl.fct.def.coroutine#6 and http://eel.is/c++draft/stmt.return.coroutine, the more I'm convinced that it's just fine that a coroutine's promise_type lacks both return_void and return_value, as long as it has no co_return and the execution never flows off the end of the coroutine itself.
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #3 from Enrico Maria De Angelis --- However, I'm not entirely sure (not anymore now that I've read the standard more carefully) that not having any of those two memebrs is an error.
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #2 from Enrico Maria De Angelis --- Created attachment 54790 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54790&action=edit Attachment for report 109323
[Bug c++/109323] New: No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 Bug ID: 109323 Summary: No error when neither of return_value or return_void is defined Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: enricomaria.dean6elis at gmail dot com Target Milestone: --- Repro: 1. take the example here -> https://en.cppreference.com/w/cpp/language/coroutines 2. remove the 3 `if (cond) co_return;` from `fibonacci_sequence` 3. remove `return_void` from `promise_type` 4. compile Alternatively: https://godbolt.org/z/v3xd3b7TE, where both GCC and Clang erroneously accept the code, whereas MSVC correcly rejects it. (http://eel.is/c++draft/dcl.fct.def.coroutine#6) I'm aware of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95517, but that makes no reference to the fact that not declaring any of the two functions is erroneous.
[Bug c++/106957] New: compiler error when calling lambda in decltype in trailing return type of function templated on T when passing T{} to the lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106957
Bug ID: 106957
Summary: compiler error when calling lambda in decltype in
trailing return type of function templated on T when
passing T{} to the lambda
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: enricomaria.dean6elis at gmail dot com
Target Milestone: ---
Created attachment 53586
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53586&action=edit
the output/error upon compilation
Repro on godbolt (https://godbolt.org/z/9T5aEnzYa)
Question on stackoverlow with a comment sayint that the code would be illegal
anyway:
https://stackoverflow.com/questions/73747517/sfinae-ing-on-a-nullary-lambda-expression-calling-a-non-templated-function-on-a
Here's the code
```
#include
constexpr auto f = [](int){};
template
auto canCallFOn(T) -> decltype([]{ f(T{}); }(), std::true_type{});
constexpr std::false_type canCallFOn(...) {
return {};
}
int main() {
static_assert(!canCallFOn(1));
static_assert(!canCallFOn(""));
}
```
[Bug c++/103403] [11/12 Regression] auto return type with a trailing return type of decl(auto) uses rvalue reference type instead of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403 --- Comment #4 from Enrico Maria De Angelis --- So there is a relation between this problem and PR 78209. At least a cause-effect relation.
[Bug c++/103403] New: Decltype of rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103403
Bug ID: 103403
Summary: Decltype of rvalue reference
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: enricomaria.dean6elis at gmail dot com
CC: anders.granlund.0 at gmail dot com,
daniel.kruegler at googlemail dot com, jason at gcc dot
gnu.org,
mpolacek at gcc dot gnu.org, trippels at gcc dot gnu.org,
webrown.cpp at gmail dot com
Target Milestone: ---
Unlike the comment at the end of the original report claims, the bug seems to
be still present (or at least a different shade of it).
StackOverflow question:
https://stackoverflow.com/questions/70092776/validity-of-presenting-an-xvalue-as-an-lvalue
Repro: https://godbolt.org/z/h943G933a
+++ This bug was initially created as a clone of Bug #78209 +++
This came up on the isocpp mailing list yesterday:
markus@x4 /tmp % cat test.ii
int main() {
int &&i = 0;
decltype(auto) j = i;
return j;
}
markus@x4 /tmp % clang++ test.ii
test.ii:3:18: error: rvalue reference to type 'int' cannot bind to lvalue of
type 'int'
decltype(auto) j = i;
^ ~
1 error generated.
markus@x4 /tmp % icpc test.ii
test.ii(3): error: an rvalue reference cannot be bound to an lvalue
decltype(auto) j = i;
^
compilation aborted for test.ii (code 2)
markus@x4 /tmp % g++ -Wall -Wextra test.ii
markus@x4 /tmp %
[Bug c++/97772] New: Wording of GCC's error message when calling lvalue-ref qualified member function on temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97772
Bug ID: 97772
Summary: Wording of GCC's error message when calling lvalue-ref
qualified member function on temporary object
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: enricomaria.dean6elis at gmail dot com
Target Milestone: ---
Long story short, write this source file
struct A {
void doWork() & {}
};
int main() {
A{}.doWork();
}
compile it with
g++ -std=c++17 that_file.cpp
and the error will be
error: passing ‘A’ as ‘this’ argument discards qualifiers [-fpermissive]
There's really no discarded qualifier; it's just that `A{}` cannot bind to the
`&`-qualified overload.
The full discussion is on StackOverflow at
https://stackoverflow.com/q/64705932/5825294
