fix: enforce expression size limit before source construction

[thesmartshadow]

This PR enforces the configured ParserExpressionSizeLimit in Env.Compile()
and Env.Parse() before calling common.NewTextSource(), preventing memory
allocation proportional to the full input size for oversized expressions.

Problem

The current flow is:

1. Env.Compile(txt) → common.NewTextSource(txt)
2. common.NewTextSource() → runes.NewBufferAndLineOffsets(contents)
3. runes.newBuffer() eagerly allocates capacity proportional to the full input
4. Only afterwards does the parser check buf.Len() > p.expressionSizeCodePointLimit

Applications configuring ParserExpressionSizeLimit(1000) expect oversized
expressions to be rejected cheaply, but the internal source/rune-buffer
materialization still occurs before enforcement.

Fix

Add an early utf8.RuneCountInString(txt) check in both Compile() and
Parse() before calling common.NewTextSource().

Before / After

• Before: 100MB compile → ~95MiB → 191MiB (returns size-limit error)
• After: 100MB compile → ~95MiB → 95MiB (same error, no memory spike)

The test TestExpressionSizeLimitEarlyEnforcement confirms 0MiB allocation
delta for a 10MB oversized expression with a 1000 code point limit.

[TristonianJones]

/gcbrun

[jcking]

Decoding the entire string twice, seems not ideal. I'd rather we just add additional funcs near common.NewTextSource and friends to take the limit and return an additional error. First we can just check the string byte length (constant time) to see if its over, otherwise we can enforce it as we go when building the buffer.

[thesmartshadow]

hi @jcking that makes sense.

I reworked the patch along those lines.

Instead of doing a separate full utf8.RuneCountInString() pass up front in Env.Compile / Env.Parse, the limit handling now lives closer to source construction.

The updated version adds limit-aware helpers near common.NewTextSource / NewStringSource, uses the cheap len(text) <= limit fast path, and otherwise enforces the code point limit incrementally while building the buffer / line offsets. It also keeps the existing default parser-limit behavior when no explicit limit is configured.

I reran the full test suite and the direct PoC as well. All tests are passing, and the compile-time memory spike is still gone with the updated approach.

[thesmartshadow]

I dropped the capHint logic and just used len(data) directly for the buffer capacities. I also added a comment there to make it a bit more obvious why that is safe.

I reran the full test suite and the direct PoC after the change. Everything is still passing on my side and the memory behavior still looks good.

[jcking]

I think we still get here if len(data) > limit, which means we will allocate the buffer even though we know we are going to go past it. I would still add the following after this if statement.

if limit >= 0 && len(data) > limit {
		return nil, nil, &SizeLimitError{
			Size:  countRemainingCodePoints(data, 0, 0),
			Limit: limit,
		}
}

[thesmartshadow]

Yeah I updated it so we return before any buffer allocation on the oversized path. I kept the code point count there so multibyte input still follows the same limit semantics.

I reran the tests after the change.

[jcking]

/gcbrun

[sucloudflare]

I independently reproduced this behavior on v0.21.0 and v0.22.1.

ParserExpressionSizeLimit() currently rejects oversized expressions only after common.NewTextSource() allocates memory proportional to attacker-controlled input size.

Using a 100MB expression with a configured 1000 code point limit produced roughly:

• +100MB RAM allocation
• ~4.3s CPU time
• error returned after allocation/parsing completed

I validated that the approach proposed in this PR mitigates the issue by enforcing limits before expensive allocations occur.

Thanks for working on this fix.