2) Just to eliminate one possibility: if callThis() returns true then callThat() is not called because the result of the logical OR expression is already known. That's an optimization done by PHP.

I know, it's pretty standard in any language :) I'm talking about that if the 2 calls are followed.

More details: cannot set a breakpoint on a conditional predicate without a block: try to set a breakpoint on doThis() or doThat() line

if($cond)
doThis();
else
doThat();

For the first case, breakpoints are tricky. Sadly PHP itself doesn't generate the correct line numbers internally. See for example the code:

<pre>
22 function test2($random)
23 {
24 if ($random)
25 test2a();
26 else
27 test2b();
</pre>

Which in PHP turns into:

<pre>
line # * op fetch ext return operands

22 0 > EXT_NOP
1 RECV !0
25 2 EXT_STMT
3 > JMPZ !0, ->8
4 > EXT_FCALL_BEGIN
5 DO_FCALL 0 'test2a'
6 EXT_FCALL_END
7 > JMP ->11
27 8 > EXT_FCALL_BEGIN
9 DO_FCALL 0 'test2b'
10 EXT_FCALL_END
28 11 > EXT_STMT
12 > RETURN null
</pre>

as you can see, there is no line 24 or 26. One of the PHP folks is looking at fixing this, but this is currently not something I can address in Xdebug. Even more annoying, the case for "false" also hits line 25 due to PHP weirdness.

I will now have a look at the second case.

By your example, I should be able to set a breakpoint on 25 or 27. Which I am not; I try to ellaborate a litle on a test case:

<pre>
1 <?php
2 function ret1(){
3 return 1;
4 }
5 function ret2(){
6 return 2;
7 }
8 function dummy1(){
9 echo 'dummy1';
10 }
11 function dummy2(){
12 echo 'dummy2';
13 }
14 if($x)
15 dummy1();
16 else
17 dummy2();
18 if(ret1()&&ret2())
19 dummy1();
20 else
21 dummy2();
</pre>

TS1:

• set breakpoints on 15,17,19,21
• expected behavior: stop on 17,19
• actual behavior: breakpoints don't work, BUT debugger inadvertently stops on line 15, BUT on "step into" command goes into dummy2 at 6

TS2:

• set breakpoint on 14
• expected behavior: stop on 14
• actual behavior: doesn't work as per your explanations

TS3:

• Step over all the way to 18
• Step into 18; correctly goes into ret1 on 3
• Step out of ret1
• Expected behavior: execution should step into ret2 on 6 (most debuggers do it this way), or _atleast on 19 so I can debug dummy1
• Actual behavior: all if is skipped; seems to step out not of the function call but of the statement
• Consequence: the only way to step into a second conditional function or the predicate function is that I have the patience to step all the way through the first conditional function or add incognito breakpoints on function entries

More discussion over TS3 where I think a definite improvement can be made: most debuggers I'm familiar with interpret debugger commands on conditional statements the following way:

• Step over if statement

• Usual: breaks on first instruction of the branch taken

• XDEBUG: breaks on first instruction after if statement

• Step into if statement

• Usual&XDEBUG: step into first function in condition

• Step out of conditional function

• Usual: break into the next conditional function then at the first instruction of branch taken

• XDEBUG: break out of if statement

Marking as "not fixable":

All cases really have the same cause.
In the first bit of TS1 (stop on 17):

It stops on line 15 because of this is where PHP places the if statement:

15 8 EXT_STMT
9 > JMPZ !0, ->1

This is something PHP should have put on line 14, but didn't. The step-into
goes correctly into dummy2 in line 12 (and not 6 like you wrote). This is
because that's what is the next executable line after the if-JMPZ has been
done.

The second case in TS1 (not stopping on line 19) is because PHP
doesn't generate an EXT_STMT, which is required for breakpoint insertions.

TS2 is indeed because PHP simply generates no code on line 14:

11 6 EXT_STMT
7 NOP
15 8 EXT_STMT

TS3 is because PHP doesn't generate an EXT_STMT before the dummy1 call,
as it would do if you would have used braces. Hence it doesn't stop and
goes directly to the next breakable line in a scope higher than where
you were (the ret1 function online 3), wich is the EXT_STMT in line 23.

You fix all of this by just using braces.

This turned out to be a duplicate of 1165, for which I now have cooked up a fix, which will make it into 2.5.1.