`DebugStruct::field_with` and friends are code size footguns

[hanna-kruppe]

I tried this code (artificial, for the sake of a self-contained example):

#![feature(debug_closure_helpers)]
use core::fmt::{self, Debug};

pub struct Point {
    pub x: u32,
    pub y: u32,
}

impl fmt::Debug for Point {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        f.debug_struct("Point")
            .field_with("x", |f| self.x.fmt(f))
            .field_with("y", |f| self.y.fmt(f))
            .finish()
    }
}

I expected to see this happen: generating roughly comparable amounts of code to the more conventional approach with DebugStruct::field.

Instead, this happened: every use of field_with with a distinct closure monomorphizes all of field_with's code, adding a hundred lines of LLVM IR per call site. For the simple example above that only calls field_with twice, cargo-llvm-lines counts 578 lines, while the version using .field("x", &self.x).field("y", &self.y) generates 42 lines.

A real-world example where I've run into is the impl fmt::Pointer for raw pointers. Here, the use of field_with causes a lot of code to be generated per pointee type. For example, consider this program:

use core::ptr::null;
use core::fmt::Debug;

type Pointers = (*mut u8, *mut u16, *mut u32, *mut u64);

pub fn force_codegen() -> Box<dyn Debug> {
    Box::new(Pointers::default())
}

cargo llvm-lines output

  Lines               Copies            Function name
  -----               ------            -------------
  1591                38                (TOTAL)
   868 (54.6%, 54.6%)  4 (10.5%, 10.5%) core::fmt::builders::DebugStruct::field_with::{{closure}}
   180 (11.3%, 65.9%)  4 (10.5%, 21.1%) core::fmt::builders::DebugStruct::field_with
   120 (7.5%, 73.4%)   4 (10.5%, 31.6%) <*const T as core::fmt::Pointer>::fmt
   103 (6.5%, 79.9%)   1 (2.6%, 34.2%)  alloc::alloc::Global::alloc_impl
    50 (3.1%, 83.0%)   1 (2.6%, 36.8%)  core::tuple::::default
    40 (2.5%, 85.5%)   4 (10.5%, 47.4%) <*const T as core::fmt::Pointer>::fmt::{{closure}}
    39 (2.5%, 88.0%)   1 (2.6%, 50.0%)  alloc::alloc::exchange_malloc
    37 (2.3%, 90.3%)   1 (2.6%, 52.6%)  core::alloc::layout::Layout::from_size_align_unchecked::precondition_check
    36 (2.3%, 92.6%)   4 (10.5%, 63.2%) <*mut T as core::fmt::Debug>::fmt
    33 (2.1%, 94.7%)   1 (2.6%, 65.8%)  core::ptr::non_null::NonNull::new_unchecked::precondition_check
    28 (1.8%, 96.4%)   4 (10.5%, 76.3%) <&T as core::fmt::Debug>::fmt
    23 (1.4%, 97.9%)   1 (2.6%, 78.9%)  <(W,V,U,T) as core::fmt::Debug>::fmt
    17 (1.1%, 98.9%)   1 (2.6%, 81.6%)  alloc::boxed::Box::new
     6 (0.4%, 99.3%)   1 (2.6%, 84.2%)  <() as core::fmt::Debug>::fmt
     6 (0.4%, 99.7%)   1 (2.6%, 86.8%)  test_field_with::force_codegen
     4 (0.3%, 99.9%)   4 (10.5%, 97.4%) core::ptr::mut_ptr::::default
     1 (0.1%,100.0%)   1 (2.6%,100.0%)  <() as core::unit::IsUnit>::is_unit

Note:

1. This is initial LLVM IR builds. LLVM easily optimizes into jumping to the fmt_pointer_inner function for Sized pointees. But it's still wasting compile time to generate all that LLVM IR, and for unsized pointee types (e.g., *mut [T]) this will probably impact binary size even with optimizations.
2. This specific impl can be fixed to avoid field_with (and that may be useful as a minor optimization even if field_with improves), but it's a nice example of how easy it is to run into the code size footgun of the current way these helpers are implemented.

Meta

rustc --version --verbose:

rustc 1.93.0-nightly (01867557c 2025-11-12)
binary: rustc
commit-hash: 01867557cd7dbe256a031a7b8e28d05daecd75ab
commit-date: 2025-11-12
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.5

[hanna-kruppe]

The standard trick for mitigating this kind of bloat (without changing the public API) is to have a trampoline erase the closure type (i.e., convert to some kind of dyn Fn*) and having the actual implementation only accept the dyn Fn*.

Doing this by redirecting to the pre-existing dynamic-dispatch-based equivalents (e.g. DebugStruct::field) is a bit tricky because those go through Debug::fmt so the closure has to be callable via a shared reference. This can be worked around with Cell<Option<_>> but that's a fair amount of machinery. A more tailored function that accepts &mut dyn FnMut(...) can at least remove the Cell part (cf. the OnceCell example in https://matklad.github.io/2021/09/04/fast-rust-builds.html#Keeping-Instantiations-In-Check).

Maybe the standard libary can do better via unstable magic. Would this signature work?

fn field_with_dyn(&mut self, name: &str, value_fmt: dyn FnOnce(...) -> fmt::Result) -> &mut Self {}

[bjorn3]

Would this signature work?

It doesn't look like we support unsizing closures to dyn FnOnce(...) -> fmt::Result in argument position. Currently the only place where we use unsized arguments is in the impl<T: FnOnce> FnOnce for Box<T> impl where the unsized argument is created by dereferencing a Box<dyn FnOnce>.

[clarfonthey]

A bit late, but is there anything we could potentially do to mitigate the code size issues with closures, or is this a difficult problem to solve?

It feels like there could be some compiler magic to sidestep the intermediate functions so that there doesn't have to be as much work optimising it out, but I also don't know enough about how this works to say. Closures being a code footgun is a very relevant issue across the board, and it feels like there should be some way to mitigate that, at least for debug builds.