On 5/21/14 8:07 PM, Nick Coghlan wrote:
Notice that line 6 (the continue) is unreachable, because the else-jump from line 4 has been turned into a jump to bytecode offset 27 (the for loop), and the end of line 5 has also been turned into a jump to 27, rather than letting it flow to line 6. So line 6 still exists in the bytecode, but is never executed, leading tracing tools to indicate that line 6 is never executed.
So isn't this just a bug in the dead code elimination? Fixing that (so there's no bytecode behind that line and coverage tools can know it has been optimised out) sounds better than adding an obscure config option.
Perhaps I don't know how much dead code elimination was intended. Assuming we can get to the point that the statement has been completely removed, you'll still have the confusing state that a perfectly good statement is marked as not executable (because it has no corresponding bytecode). And getting to that point means adding more complexity to the bytecode optimizer.
Potentially less risky would be to provide a utility in the dis module to flag such lines after the fact.
I don't see how the dis module would know which lines these are? I'm surprised at the amount of invention and mystery code people will propose to avoid having an off-switch for the code we already have.
Cheers, Nick.