pub const MAX_TOML_NESTING_DEPTH: usize = 64;Expand description
Maximum allowed nesting depth for TOML table/array recursion before
check_toml_nesting_depth rejects the input.
Counts both [/{ bracket depth and dotted-key/table-header segment
count (e.g. a.b.c or [a.b.c]), since both drive toml-span’s
recursive descent.
toml-span 0.7.1’s recursive-descent parser has no recursion limit, so
either a deeply nested [[[...]]] array/{{{...}}} inline-table
literal, or a dotted key/header with many .-separated segments, can
overflow the native thread stack and abort the whole process (SIGABRT)
before toml_span::parse ever returns an error. As a library, deps-core
cannot rely on its consumers raising their stack size, so this constant
deliberately assumes the smallest stack any caller is likely to run on: a
tokio worker thread’s 2 MiB default (relevant since lock file parsing
runs inside tokio::spawn), not the platform’s larger 8 MiB main-thread
default. deps-lsp, the one consumer in this workspace, additionally
raises its tokio worker stacks to 8 MiB as defense-in-depth on top of
this guard (see WORKER_THREAD_STACK_SIZE in deps-lsp’s main.rs), but
the constant itself stays sized for the 2 MiB floor. Stack cost per level
is also shape-dependent: nested inline tables ({a={a=...}}) cost
noticeably more per level than nested arrays in a debug build.
Bisected against the real toml_span 0.7.1 recursion on a 2 MiB stack:
a debug build survives depth 220 for inline tables / 305 for arrays; a
release build survives roughly 2485 / 1805. 64 leaves a >3x margin under
the tightest of these (debug inline tables, 220) while still being far
deeper than any real manifest needs — across a corpus of thousands of
real-world .toml files, the deepest observed bracket nesting was 5 and
the deepest dotted-key path was 6 segments.