[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

[prlw1 at cam dot ac.uk via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393

--- Comment #9 from Patrick Welche  ---
Thank you!

$ /usr/local/gcc/bin/g++ --version
g++ (GCC) 14.0.1 20240414 (experimental)
$ ./readme_ex
0 1 4

[Bug c++/114393] New: over eager "invalid use of void expression" ?

[prlw1 at cam dot ac.uk via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393

Bug ID: 114393
   Summary: over eager "invalid use of void expression" ?
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prlw1 at cam dot ac.uk
  Target Milestone: ---

When trying to use the reference implementation of the `std::execution`
proposal over at https://github.com/nvidia/stdexec, I get errors of the form

/usr/src/local/stdexec/include/exec/async_scope.hpp:735:31: error: invalid use
of void expression
  735 | return when_empty(just());

with `g++ (GCC) 14.0.1 20240318 (experimental)`

In https://github.com/NVIDIA/stdexec/issues/1285 Eric Niebler traces this to
a__make_sexpr invocations which can't ever have type void.

The easiest way to reproduce this is to see the standard example on goldbolt:
https://godbolt.org/z/3cseorf7M

It compiles fine with gcc 12.3 and 13.2 (even with `-Wall -Wextra
--pendantic-errors`, but not with gcc trunk, which possibly suggests a
regression.

I have been using stdexec successfully for a while with trunk. Old checkouts of
stdexec which used to work (with maybe gcc trunk from about 2 months ago?) now
fail, which also points towards a change in gcc rather than in stdexec.

[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?

[prlw1 at cam dot ac.uk via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201

--- Comment #9 from Patrick Welche  ---
sorry for jumping the gun...

[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?

[prlw1 at cam dot ac.uk via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201

Patrick Welche  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Patrick Welche  ---
I can confirm that this is now fixed. Thank you!

[Bug libstdc++/106201] New: filesystem::directory_iterator is a borrowable range?

[prlw1 at cam dot ac.uk via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201

Bug ID: 106201
   Summary: filesystem::directory_iterator is a borrowable range?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prlw1 at cam dot ac.uk
  Target Milestone: ---

In the following:

#include 
#include 
#include 
#include 

int main()
{
auto print = [](const auto& x) {std::cout << x << '\n';} ;

std::ranges::for_each(
std::views::iota(1) | std::views::take(5),
print
);

std::ranges::for_each(
std::filesystem::directory_iterator("/"),
print
);

std::ranges::for_each(
std::filesystem::directory_iterator("/") | std::views::take(3),
print
);  
}

the first two for_each clauses compile and execute correctly, even with g++
10.3.0.

Is my expectation that the third clause is valid incorrect?

(I just tried with today's head, g++ (GCC) 13.0.0 20220705 (experimental) and
it failed to compile.)

Oh: https://cplusplus.github.io/LWG/issue3480
But: it says "could be fixed ... (as libstdc++ currently does anyway)"
Issue looks resolved?
Thoughts?