Adjust assignment line number for match

[iluuu1994]

Otherwise the assignment will have the same number as the default arm which will 1. mis-trigger a breakpoint and 2. mark the line as covered even when it isn't.

/cc @derickr

@nikic The line number does not need to be reset, right? Tests are passing but I don't think line numbers are extensively tested.

[derickr]

This currently breaks a whole bunch of tests for me in Xdebug now, will investigate why over the next few days.

[iluuu1994]

@derickr Ok, let me know if those changes make sense or if this needs more tweaking.

[iluuu1994]

@derickr Btw can you also try this and see if the output of your tests is any different?

uint32_t tmp = CG(zend_lineno);
CG(zend_lineno) = zend_ast_get_lineno(var_ast);
zend_emit_op_tmp(result, ZEND_ASSIGN, &var_node, &expr_node);
CG(zend_lineno) = tmp;

[nikic]

Looks good to me, but let's wait for Derick.

[nikic]

Suggested change

	default => 'bar',
	default => 'bar', // breakpoint #0

Maybe, so one doesn't have to count lines.

[derickr]

Yes, this looks good now I've checked my test cases. The funny thing is that these test cases test for a feature in Xdebug that "resolve" lines where people (IDEs) set breakpoints, to the nearest line that has an actual EXT_STMT on it, but finding an earlier or later line. They (almost all) test:

$a = array(
    'a',
);

Before this patch, the EXT_STMT and ASSIGN where on the 'a', line, so Xdebug resolved a breakpoint set on the line with $a = array( to the one below (with the EXT_STMT). Which your patch, the ASSIGN and EXT_STMT correctly show up at the user-expected '$a = array(` line, but that of course thwarts my test that tested the resolving!

In any case, this now works as expected, so I'm just going to have to come up with new tests :-/.