A hex int literal passed as a macro parameter forgets its identity and gets stringify!-ed as a decimal int literal

[nodakai]

Minor papercut:

macro_rules! m {
    ($e: expr) => (stringify!($e))
}

fn main() {
    println!("{:?}", stringify!(1 +1));
    println!("{:?}",         m!(1 +1));
    println!("{:?}", stringify!(0xff));
    println!("{:?}",         m!(0xff));
    println!("{:?}", stringify!(1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001));
    println!("{:?}",         m!(1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001));
}

• https://play.rust-lang.org/?gist=c71dd261fd16facbeeecb4be4444df4a&version=stable&backtrace=0

"1 + 1"
"1 + 1"
"0xff"
"255"
"1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001"
"1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001"

0xff is converted into 255 while 1.000....1 isn't (the delta from 1.0 is clearly smaller than IEEE854 double's machine epsilon)

May or may not be related to #28415

[TimNN]

The reason for this is the way they are represented at the time macro expansion happens: Integers are stored as a u64 value, their representation in the source is lost. Float literals are stored as strings at this point.

[nodakai]

@TimNN Thanks for the info, that's exactly what I expected from the above observations.

And I'd claim such an implementation detail should not affect an observable behavior of a programming language.

Ideally stringify!(1 +1) should yield "1 +1" rather than "1 + 1" but this is acceptable for me at the moment.

[Mark-Simulacrum]

Output today is:

"1 + 1"
"1 + 1"
"0xff"
"0xff"
"1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001"
"1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001"

which is pretty much what we'd expect I think so going to go ahead and close.