Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the PPI CPAN distribution.

Report information
The Basics
Id: 75038
Status: open
Priority: 0/
Queue: PPI

Owner: Nobody in particular
Requestors: jgangemi [...]

Bug Information
Severity: Normal
Broken in: 1.215
Fixed in: (no value)

Subject: 10_000.10_000.10_000 does not parse to a Number::Version token
Download (untitled) / with headers
text/plain 865b
according to the documentation in Number::Version, 10_000.10_000.10_000 should be a version number but PPI parses it into two float tokens. PPI::Token::Number::Float '10_000.10_000' PPI::Token::Number::Float '.10_000' looking at the source in Number::Float, i see the following: } elsif ( $t->{token}->{content} !~ /_/ ) { # Underscore means not a Version, fall through to end token $t->{class} = $t->{token}->set_class( 'Number::Version' ); return 1; } which leads me to believe the !~ should actually be a =~, although making that change locally produces this: PPI::Token::Number::Version '10_000.10_000.10' PPI::Token::Word '_000' which is still incorrect, but getting there. :) before i go hunting down where the rest of the potential bug is, i just want to confirm that the string really should parse to a Number::Version token. -- -jae
Download (untitled) / with headers
text/plain 353b
upon further inspection, changing the !~ to =~ breaks version strings that look like this: so perhaps the 'elsif' should really just be an 'else', which creates a proper Number::Version token, except in the case above where it produces the extra Word token, which i am still investigating. it seems to occur after PPI sees a 3rd '.' -- -jae
Download (untitled) / with headers
text/plain 303b
ok... assuming '10_000.10_000.10_000' should be a Number::Version token and changing the 'elsif' to an 'else' in Number::Float::__TOKENIZER__on_char is correct, then Number::Version::__TOKENIZER__on_char needs this added to it: # Allow underscores straight through return 1 if $char eq '_'; -- -jae
This issue is now being tracked on GitHub as

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to