provide originating context of subroutine definitions #10628
Comments
From jawnsy@cpan.orgCreated by jawnsy@cpan.orgI noticed that subroutine redefinition messages from perl are not as helpful as they could be. If we redefine something in perl, we get: $ perl -we 'sub blah { 1; }; sub blah { 2; }' Compiling a C program (using gcc) with redefinitions results in: $ cc -std=c99 -pedantic -Wall -g -O0 -DDEBUG -I. -fPIC -c display.c -o display.o In a brief chat with the #toolchain folks, at first glance, it might be possible to add this feature (though it could be non-trivial to handle some of the obscure cases) <jawnsy> question: why isn't perl's message -- Subroutine blah redefined at -e line 1. -- more informative, like gcc's? (gcc shows the origin of the first definition) In case this actually isn't possible, then I apologize for the noise. I just thought it'd be a nice feature, and could help to make perl (the binary) more friendly for new users. Perl Info |
From jawnsy@cpan.orgAdditional information was sent to me via e-mail from Brad Gilbert This code should also look for places where the code was set by a GLOB *newsub = \&oldsub If you don't check for this, your message might say where oldsub() was |
From @doyPushed an implementation of this to the doy/better_redefinition_warnings |
|
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Sat Jun 23 21:32:09 2012, doy wrote:
Maybe 2833323 was premature. What happens if you revert 2833323? -- Father Chrysostomos |
From @doyOn Sat, Jun 23, 2012 at 11:21:20PM -0700, Father Chrysostomos via RT wrote:
SAVECOPSTASH no longer exists, and I'm not sure what to use instead. Any -doy |
From @cpansproutOn Sat Jun 23 23:43:17 2012, doy@tozt.net wrote:
SAVECOPSTASH_FREE will do. It doesn’t actually free anything any more. -- Father Chrysostomos |
From @doyOn Sun, Jun 24, 2012 at 12:05:21AM -0700, Father Chrysostomos via RT wrote:
No difference. This actually looks like an off-by-one error of some kind -doy |
From @cpansproutOn Sun Jun 24 01:20:59 2012, doy@tozt.net wrote:
Sorry. I wasn’t thinking.
What I see is this: sensical line numbers I’m getting line -1. This code for setting the line number is very odd indeed. newCONSTSUB has everything within an ENTER/LEAVE pair, in which it does SAVECOPLINE(PL_curcop); I don’t fully understand how the parser setup happens, but I think that It needs to set PL_curcop to &PL_compiling, because it has to modify it But this test script gives the right line number (it does go through use constant { foo => 1, bar => 2}; And then newXS_len_flags also plays around with the line number, as you saw: const line_t oldline = CopLINE(PL_curcop); I’m not even sure that’s thread-safe. newXS can be called from Also, it’s probably wrongly using the parser’s line number. I’m not sure I want to debug this quagmire just yet. :-) I’ve had a look at your patch, and there is one problem with it (apart #!perl -w $foo = 'squiggles'; sub foo { 1 } sub foo { 2 } I don’t even know what the line number in the GV is for. Maybe it would -- Father Chrysostomos |
From @cpansproutOn Sun Jun 24 11:01:21 2012, sprout wrote:
I do now. :-) It is used for ‘use once’ warnings. If the GV is accessed multiple -- Father Chrysostomos |
Migrated from rt.perl.org#77816 (status was 'open')
Searchable as RT77816$
The text was updated successfully, but these errors were encountered: