it seems LLVM doesn't realize that `curr` is always decremented at least
once in either loop formatting characters of the input string by their
appropriate radix, and so the later `&buf[curr..]` generates a check for
out-of-bounds access and panic. this is unreachable in reality as even
for `x == T::zero()` we'll produce at least the character
`Self::digit(T::zero())` for at least one character output, and `curr`
will always be at least one below `buf.len()`.

adjust `fmt_int` to make this fact more obvious to the compiler, which
fortunately (or unfortunately) results in a measurable performance
improvement for workloads heavy on formatting integers.

…'t work

this test was included for demonstrative and discussion purposes but does not test what its name alleges - in fact it does not test much of value at all!

as mentioned in this comment, rust-lang#122770 (comment) , writing a correct test for this codegen outcome is difficult (partially because the public interface to std::fmt intentionally includes an #[inline(never)] function!), so to test this correctly will require more than i can offer in 122770.