impl fmt::Display for u32 compiles to large binary

[StackOverflowExcept1on]

My target is wasm32-unknown-unknown but I think it can be applied to any embedded systems. I just want to define panic handler, but formatting core::panic::Location costs amlost 3 KiB in binary. This is because inefficient impl Display for u32. Also see: https:/dtolnay/itoa

[package]
name = "demo"
version = "0.1.0"
edition = "2021"

[lib]
name = "demo"
crate-type = ["cdylib"]

[dependencies]
arrayvec = { version = "0.7.4", default-features = false }

[profile.release]
opt-level = "z"
codegen-units = 1
lto = true
strip = true

#![no_std]
#![feature(panic_info_message)]

#[allow(improper_ctypes)]
extern "C" {
    pub fn sc_panic(msg: &str) -> !;
}

#[panic_handler]
fn panic(panic_info: &core::panic::PanicInfo) -> ! {
    use core::fmt::Write;

    let mut msg = arrayvec::ArrayString::<1024>::new();

    // 2_009 bytes binary:
    /*let _ = write!(&mut msg, "{}", unsafe {
        panic_info.message().unwrap_unchecked()
    });*/

    // 5_076 bytes binary:
    let _ = write!(&mut msg, "{}", unsafe {
        panic_info.location().unwrap_unchecked()
    });
    // ^^^ +3 KiB to print location in format {file}:{line}:{column}???

    // exit from smart contract with msg
    unsafe { sc_panic(&msg) }
}

#[no_mangle]
extern "C" fn entry_point() {
    panic!("msg");
}

This is mostly because this line:

rust/library/core/src/fmt/num.rs

Line 277 in 1aa6aef

f.pad_integral(is_nonnegative, "", buf_slice)

Could we have something like specialization for more simpler impl Display for $num?

[GKFX]

At present, both {} and (e.g.) {:06} pass the integer to Argument::new_display, which returns a pointer to Display::fmt unconditionally. new_display doesn't see whether this has extra flags or not so it has no opportunity to return a simplified formatting function. You would have to change format_args to give new_display visibility of the Placeholder struct to allow a specialized formatting function to be returned instead. (Edit: a new_simple_display was tried in #104525 but not merged, with tracking issue #99012.)