ParseXS - Disable alias value collision warnings by default #20517
Conversation
demerphq
force-pushed
the
yves/dev_mode_parsexs
branch
2 times, most recently
from
fa6606c to
6cc0635
Compare
We always had a bug with the value 0, when fixing it, we discovered a lot of people were doing duplicate aliases with 0. This patch disables the warnings except when in a special author mode, as it makes no sense to show these warnings to end users. It would seem most times creating such aliases is not an issue and is entirely deliberate. So showing such warnings only to module authors and only on request also makes sense.
demerphq
force-pushed
the
yves/dev_mode_parsexs
branch
from
6cc0635 to
40db0dd
Compare
|
Those last pushes include tests and a fix for perl 5.8 |
Could you be a bit more specific in this commit message, e.g., a reference to a bug ticket or a user complaint? How far back in time does always cover?
|
What about perl-5.8 needed to be fixed? |
|
I can confirm that this does turn off the warnings that begin with There were 15 such warnings being generated in blead at eae8123. |
I don't specifically. I haven't checked. It wouldn't surprise me if it either dates back to Larrys code on xubpp, or the refactor that produced ParseXS, or alternatively I would not be surprised if the warning was added after the fact, and was misimplemented when it was.
In the initial push of this patch I used |
I said before I noticed it while I working on silencing the non-buggy part of the warning.
Long enough that we have multiple files in core that exploit the bug. See #20496 (comment) |
|
I checked, it is present in the original version of ParseXS from 2005: commit 6b09c16 |
|
@tonycoz any thoughts on this? id like to merge tomorrow. |
|
Im going ahead with this. I dont think it makes anything worse. |
We always had a bug with the value 0, when fixing it, we discovered a lot of people were doing duplicate aliases with 0. This patch disables the warnings except when in a special dev mode, as it makes no sense to show warnings like thus to end users, its not a system issue its a code issue, and only the XS files author can fix it. It would seem most times its not an issue and is entirely deliberate. So showing such warnings only on request also makes sense.