pub const MAX_BLOCK: u32 = 2048;Expand description
How many statements one block may hold before the front end refuses it.
A second axis, and 64 §64.4 is why it
exists: a body of sequential local bindings is flat, so v0 = … followed by v1 = … sits at
nesting level 2 and MAX_NESTING never sees it — while the front end recurses once per
binding anyway, because a block is a chain in Core whatever it looks like in source. That
report measured the consequence: a debug build aborted at 12,000 bindings and a release build at
100,000, with no diagnostic, so which programs compile depended on how the compiler was built.
It is much larger than MAX_NESTING because the two axes are not comparable. Nesting 256
levels deep is pathological; writing 256 sequential bindings in one function is merely long, and
a generated or macro-expanded body can be longer still. The number is chosen the way
adr/0012 chose the
other: the_block_ceiling_fits_the_declared_stack measures the checker at 6.8 KiB a
statement in an unoptimised build, so 2,048 of them cost 14 MiB and 28 MiB with the doubled
margin — comfortably inside STACK_BYTES, and with room for a future pass to make a frame
bigger without silently spending the headroom. That test is in beck-core::check and fails if
the declaration stops covering the ceiling.