Bug #69712 for Devel-Comments: labelled expression returning no values

"Xiong Changnian via RT" <bug-Devel-Comments@rt.cpan.org> writes: Show quoted text
Bug for bug compatibility :-). Show quoted text
My suspicion is Data::Dumper doesn't enjoy an empty values list, or the post-dump crunch, or something. Show quoted text
I like those, as it's good to distinguish undef from empty string, and from a string "undef". Show quoted text
I think it should distinguish no-values from a single undef value -- assuming the expression is run in array context, which is what Smart::Comments has done, and which is handy for a list of values or list return from a function. ### blah: $x,$y,$z Show quoted text
I opened a couple of tickets against Smart::Comments too. Colon in labelled expression would probably be top of my list https://rt.cpan.org/Ticket/Display.html?id=55641 which I think Devel::Comments has inherited, eg. use Devel::Comments; { package xx; sub foo { 123 } } ### expr: 1 ? 2 : 3 ### expr: xx::foo() prints ### expr: 1 ? 2 : 3 Undefined subroutine &main::foo called at x.pl line 6. I think the labelled epxression regexp is a bit greedy and goes to the last colon, which means you can't use a ?: or a fully-qualified package var or func. Dunno if anyone would have been using colons in the label part, and wanting them as part of the label. I'd think it more useful to have qualified func names xx::foo() than colons in the label ...

Let's try that again. Hi Kevin, Thanks for reminding me: I *have* promised drop-in replacement behavior for v1.x.x; but I've also promised to fix bugs raised against Vanilla; there is perhaps some inconsistency here. I've told feature requestors to wait for v2.0.0. But *this* clearly is a bug. I smell it in the post-dump crunch spanning lines 1453-1456: 1454: $dumped =~ s/\$VAR1 = \[\n//; To me, that looks very like the line written specifically to fix this very bug. Which it does not do. The culprit, I suspect, is: 1436: # Handle a prefix with no actual variable... 1437: if ($prefix && !$defined_varref) { ... 1442: return 1; # ...abort if not defined $varref 1443: } Having come so far, I might as well fix it, right? Let me see if I can saddle up the old hoss for one last ride. As far as a less-greedy colon-eater, well, I think I'd have to call that a requested feature. Feel free to open a ticket on it but this opens the big can of worms: the immense FILTER call which does a single pass on the entire user code with multiple regexes. I did not like the way it was written in Vanilla and, having spent quite a bit of time fiddling with it, I still don't like it. Thanks, Xiong Changnian

Okay, Kevin, Please ignore my flailing around with RT. I have that figured out now. Sorry. I've "fixed" your bug. Thinking it over, I decided to have D::C report: ### foo: null in your case. Your code: sub foo { return; }; does indeed return an undefined value; for sub foo { return; }; my $ding = defined foo; I checked that $ding is false; your code does not merely return an empty string or whatnot. I checked this because, for some incomprehensible reason, Data::Dumper seems to make a distinction between your code and a simple undefined scalar: $VAR1 = [ undef ]; Your code is reported as: $VAR1 = []; This is unique among the various empty, undef, and zero values I've tried. I have no idea why or even how D::D is able to distinguish between this undefined value and that. In any case, it *does*; so I've preserved that information and caused D::C to report 'null'. As far as the fix itself is concerned, I was wrong and you were right; the difficulty was all in the post-D::D cleanup code. The section of code I quoted earlier does not test for an undefined *value* but for an undefined value parameter reference. {face palm} Half of your bug was in the stuff that deleted the '$VAR1', etc. placeholder; half was in the indent-outdent monkey business. I "fixed" this with a bag on the side of the kludge and I'm pretty unhappy with my work. But it does resolve the issue and does not seem to have introduced new ones. Now, if I can just remember how my build system worked, I'll bump and release. Thanks, Xiong Changnian

Fixed, released, ticket closed. Thanks Kevin!

"Xiong Changnian via RT" <bug-Devel-Comments@rt.cpan.org> writes: Show quoted text
Well, it's a fairly bad misfeature as it stands ... Show quoted text
It looks like it accumulated a few cases, and might be sensitive to the order they're checked, but other than that it's not too bad. The way the last is an unlabelled expression is a bit worrying, as it might potentially execute all sorts of typos, though changing that may be incompatible.

Hi Kevin, Would you please open a new ticket for the colon-eating issue? Unless the labelled expression bug is not fixed for you in v1.1.4, I'd like to close *this* ticket. Thanks, Xiong