Fix: Large numbers lose precision in localized messages

[naoNao89]

Big numbers like i64::MAX were showing up wrong in error messages because fluent-rs converts everything to f64 internally. This breaks numbers beyond ±2^53.

Quick fix: check the range first. If it's too big for f64 to handle safely, we pass it as a string instead. Now 9223372036854775807 shows correctly instead of 9223372036854776000.

This is a temporary workaround until fluent-rs fixes their precision issue upstream.

Closes #9294

Related: projectfluent/fluent-rs#337

[mfontanaar]

I think the approach is still bugged, because you are leaving out the case of having a u64 greater than i64::MAX.

I had created a (rough) PR which I think functionally is more correct, but whose code is very ugly (yours is much more polished). You can see the relevant commit here: temp-mfontanaar@4bb0e01

That being said, I'm puzzled about how does your approach works. In my tests, it seemed like FluentArgs was always converting to a f64 , regardless of whether the input was str or i64. But your passing tests are proving me wrong.

[naoNao89]

hmm

[sylvestre]

not super happy that it will be added this in every call of translate!()

[naoNao89]

Extracted logic to safe_set_fluent_arg() helper

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will degrade performance by 9.77%

_{Comparing naoNao89:fix-9294-big-number-precision (828d18c) with main (836e0cb)}

Summary

⚡ 2 improved benchmarks
❌ 2 regressed benchmarks
✅ 138 untouched benchmarks
⏩ 180 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	nl_many_lines[100000]	46.1 ms	44.7 ms	+3.17%
⚡	Simulation	nl_large_file[10]	58.8 ms	56.9 ms	+3.22%
❌	Simulation	unexpand_many_lines[100000]	258.7 ms	286.7 ms	-9.77%
❌	Simulation	unexpand_large_file[10]	542.3 ms	601 ms	-9.77%

Footnotes

1. 180 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/misc/tee (passes in this run but fails in the 'main' branch)

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/overlay-headers (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/misc/tee (passes in this run but fails in the 'main' branch)

[sylvestre]

i think it has a bit too much complexity for a corner case :/

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/overlay-headers (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/misc/tee (passes in this run but fails in the 'main' branch)

[mfontanaar]

Where are we standing with this MR? I think it is important to try to provide some kind of workaround to the fluent limitation.

[sylvestre]

Some improvements before it can be merged:

• Logic bug: i64::MIN.unsigned_abs() handling is incorrect - i64::MIN cannot be represented as a positive i64
• Performance issue: Multiple string parsing attempts (i64→u64→f64) instead of single parse + range check
• Casting issue: u64 values are cast to i64 which can overflow for values > i64::MAX
• Performance concern: Macro now allocates strings for all arguments, impacting hot paths

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/printf/printf-surprise is now passing!

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/printf/printf-surprise is now passing!

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/tty/tty-eof (passes in this run but fails in the 'main' branch)

[sylvestre]

please reopen when ready (or ping me)
thanks