[maoxor]

--verify normalises number literals before comparing the two ASTs: it tries f64, then hexadecimal as i64, then (Luau) binary, and hits unreachable!() otherwise. Two kinds of valid literals end up there:

• hexadecimal floats, valid since Lua 5.2: 0x1p4, 0xA.8p0, 0x.1p1, 0x1.8;
• hexadecimal integers above 0x7fffffffffffffff, such as 0xffffffffffffffff.

$ echo 'local x = 0x1p4' | stylua --verify -
thread '<unnamed>' panicked at src/verify_ast.rs:148:39:
internal error: entered unreachable code

I ran into it on lua-language-server's test/parser_test/ast/Number.lua.

Hexadecimal integers are now parsed as u64, and anything that still doesn't parse goes through a small normalise_hex_float, which computes the value from the mantissa and the binary exponent. If even that fails, the literal is kept as written rather than panicking.

Tests: test_equivalent_hex_numbers_beyond_i64, test_equivalent_hex_float_numbers and test_different_hex_float_numbers all panic without the change. cargo test passes with the default features, --no-default-features, --all-features and each of lua52, lua53, lua54, luau, luajit, cfxlua; cargo clippy --all-features -- -D warnings and cargo fmt --check are clean. I also ran a release build with --verify over about 6,000 Lua/Luau files (Neovim plugins, KOReader, awesome, Kong, APISIX, lua-language-server, Roact, Fusion, ...): there are no more panics.