Re: Bison parser exhibiting weird behavior

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)=20

You might try adding assertions to your actions up at the Bison level.
If all is as you say, then

 =A0=A0=A0 block_expr '\n'
 =A0=A0=A0 {$$ =3D new_expression(exprBlock, 1, $1);
	assert( $$->type =3D=3D exprBlock);
	}

should be true and=20

 =A0 | block_list block_expr '\n'
 =A0=A0=A0 {
	assert($1->type =3D=3D exprBlock);
	assert($1 !=3D $2);
	expression_add_child($1, $2);

should be true.=20

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. =20

> and more surprisingly, $1 =3D=3D $2

I just don't think that's possible, if $1 and $2 are pointers.  If they
are values and operator=3D=3D is overloaded, that's another story. =20

HTH.