Using signatures makes the debugger harder to use #22602
Comments
|
state ops (nextstate, dbstate) are generated for each argument, which is what the debugger uses for stepping: These appear to be deliberate, both sigscalarelem and sigslurpsigil in perly.y both add state ops. @iabyn might know why. |
|
On Tue, Sep 17, 2024 at 06:53:04PM -0700, Tony Cook wrote:
state ops (nextstate, dbstate) are generated for each argument, which is what the debugger uses for stepping:
These appear to be deliberate, both sigscalarelem and sigslurpsigil in perly.y both add state ops.
@iabyn might know why.
The original signature implementation (largely by Zefram) just planted
a lot of standard perl ops to process signatures as if the signature
handling had actually been written in perl. So for example:
sub f ($a, $b = 1) {}
deparsed as:
sub f {
die sprintf("Too many arguments for subroutine at %s line %d.\n", (caller)[1, 2]) unless @_ <= 2;
die sprintf("Too few arguments for subroutine at %s line %d.\n", (caller)[1, 2]) unless @_ >= 1;
my $a = $_[0];
my $b = @_ >= 2 ? $_[1] : 1;
In that implementation, each item of parameter processing was separated by
a nextstate op, which (among other things) ensured that the taint state
was reset after each assignment (so one tainted arg wouldn't taint
subsequent parameter values), and line numbers for warnings etc would be
correct(ish).
When I added the sigFOO ops, I kept the nextstate ops: mainly in an attempt
to preserve current behaviour as much as possible. I always intended
that such sigFOO ops would be an intermediate step, and they would all be
replaced by a single OP_SIGNATURE op in the peephole optimiser which would
(via a mini state machine) do all the sig processing in a single op,
with any taint resetting etc done by the OP_SIGNATURE, with no
OP_NEXTSTATEs left.
I don't think I ever considered how the debugger would be affected.
…--
Standards (n). Battle insignia or tribal totems.
|
|
While I was looking at how to implement named params, I had vague thoughts in mind for neatening up the signature things overall; much as Dave suggests there. In the longterm I don't imagine there'll be as many OP_NEXTSTATE (or DBSTATE) ops involved. In the short-term, I wonder if we could try simply not emitting so many of them. Since conceptually every defaulting expression for optional params does execute like a statement, those ought to be retained, but there's probably no need to have one on the OP_ARGCHECK nor the mandatory params without a defaulting expression. Failing that, there's likely a spare private bit on the OP_DBSTATE that we can use to signal to the debugger not to count that one, so as to preserve the tree-shaped structure for code that wants to inspect the optree, but allowing the debugger to skip over those. |
|
There was some discussion in IRC covering this earlier:
|
With the debugger enabled the argcheck op and each argelem op generated to process a function signature would have an associated dbstate op, allowing the debugger to step on that op. This can be confusing and/or onerous when stepping through code, since for a signature with 7 arguments you'd have 9 steps to get past the prologue of the sub. Make most of these dbstates into nextstates to make them non-steppable. Fixes Perl#22602
With the debugger enabled the argcheck op and each argelem op generated to process a function signature would have an associated dbstate op, allowing the debugger to step on that op. This can be confusing and/or onerous when stepping through code, since for a signature with 7 arguments you'd have 9 steps to get past the prologue of the sub. Make most of these dbstates into nextstates to make them non-steppable. Fixes Perl#22602
Description
When using the debugger (
perl -d $program), you can use thescommand to step through lines of code, one at a time. However, this is not true for subroutine signatures. When youstep through one of these subs, you have tostep through the signature at N+1 times, where N is the number of variables in the signature. These extra steps are not obvious, because nothing visible is happening, and they can be confusing. More than once I've accidentallystepped over the first line of a sub/method because I hit "return" too many times on a signatures.This makes using the already cumbersome debugger CLI even more cumbersone.
It does not affect subroutines without signatures, even if they have a prototype (since the latter is compile-time, not run time).
This appears to affect all versions of Perl which allow signatures, whether by default, or when using the experimental signatures feature.
Steps to Reproduce
Run the following program with
perl -d:Expected behavior
When running the above program with the debugger, when you try to step into the first sub, you immediately get into the body of the sub:
I expect the debugger to never stop on the signature line, or at minimum, to only stop once (because we might need to see the defaults).
However, for all subs with signatures, you must repeat the
s(or just hit "return" to reuse the last step command) N+1 times for every variable in the signature, even though it's not obvious to the programmer that runtime behavior is occurring here:However, you can verify runtime behavior if you print out the value of those variables after every
step:That being said, I've never felt the need to dump signature variables while they're being individually assigned.
Perl configuration
The text was updated successfully, but these errors were encountered: