On Fri, 20 Oct 2023, Nathan Sidwell wrote:
> Thanks for looking at this, but your patch is essentially papering over the
> problem.
>
> It took me a while to figure out, but the clue was that things like
> 'decltype(f()).m' worked, but 'decltype(f()){0}' did not. The CONSTRUCTOR
> node is the ex
Thanks for looking at this, but your patch is essentially papering over the
problem.
It took me a while to figure out, but the clue was that things like
'decltype(f()).m' worked, but 'decltype(f()){0}' did not. The CONSTRUCTOR node
is the exception to the rule that required an expression node
On Wed, 18 Oct 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
Note that this doesn't fix the other testcase in the PR, which doesn't use any
lambdas and which ICEs in the same way:
export module pr105322;
auto f() {
s
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For a local variable initialized by a lambda:
auto f = []{};
The corresponding BLOCK_VARS contains the variable declaration first,
followed by the closure type declaration, consistent with the
syntactical