On Sat, 6 Sep 2025 11:01:47 +0200
Fr <[email protected]> wrote:
> Upon inspection with GDB, it seems like when the assertion fails, $1
> is of type exprVar (a possible expression type for a block_expr)
You might try adding assertions to your actions up at the Bison level.
If all is as you say, then
block_expr '\n'
{$$ = new_expression(exprBlock, 1, $1);
assert( $$->type == exprBlock);
}
should be true and
| block_list block_expr '\n'
{
assert($1->type == exprBlock);
assert($1 != $2);
expression_add_child($1, $2);
should be true.
My guess would be that block_expr can be constructed by some other rule
(possibly one that doesn't require \n) that produces an exprVar, and
then the list is constructed. Or new_expression() is not doing what's
expected.
> and more surprisingly, $1 == $2
I just don't think that's possible, if $1 and $2 are pointers. If they
are values and operator== is overloaded, that's another story.
HTH.
