fix: decrease a call limit on the toml fuzzer

[tomtau]

closes #697

[NoahTheDuke]

Weird that it's failing now but wasn't failing earlier. Looks like this sample is truly a worst case scenario. Should the limit be lowered even more?

[CAD97]

Ideally we'd determine what the actual limit is to avoid an OOM. And ideally max usage should be linear on the limit, so there shouldn't be a case where one input hits the limit but another OOMs...

[CAD97]

(Meta note: I don't know why the maintainers review request is being converted to an individual but the team isn't.. perhaps it's the fact that the requested maintainer is also on the triage team? But then why do I have a requested review? I think what's happened is that GH has routed the triage request to me but not updated that in the reviewers list?)

[tomtau]

@NoahTheDuke this one is weird that I managed to reproduce it locally (the sample crashes even VSCode's parser sometimes when I try to open it)... the limit I set passes on my machine locally, but fails on CI for some reason

[tomtau]

@NoahTheDuke when running the tests with --release on CI, it seems to work fine: https://github.com/pest-parser/pest/actions/runs/2876875272

[CAD97]

--release

Ah yes, definitely, anything dealing with resource exhaustion will change thresholds in release and debug mode, because debug has zero optimization. Notably, if you have any bindings which are not live for the entire function, stack space for all of them to be live simultaneously is reserved in debug mode and bindings which are not live in the same control flow are only overlapped once optimizations kick in. This can in a case with a bunch of match arms make the difference of multiple orders of magnitude of stack space. And it doesn't have to be named bindings, either; just temporaries (e.g. calling a method, doing basically anything other than a literal) is enough to generate locals which debug mode pessimistically assumes could be live for the entire function.

There's two reasonable resolutions AIUI:

• Mark resource-exhaustion tests as #[ignore]; test them with --include-ignored in --release mode
• Make the resource limits depend on cfg(opt_level) (which needs to be sniffed in the buildscript, or debug_assertions as a proxy)

[tomtau]

@CAD97 I'd prefer the #[ignore] option, because I wasn't able to reliable reproduce the CI behaviour locally in the debug mode (i.e. tests didn't crash with the set limit, unlike CI), so there may be a few more runtime and toolchain variables than just the optimization level. Unfortunately, --include-ignored fails due to a handful of ignored illustratory doc examples that don't build (one alternative for them may be to change them to text instead of ignore, but that would lose syntax highlighting).

Anyway, let's go with the second option for now (I feature-guarded that problematic sample execution with #[cfg(not(debug_assertions))]).

[CAD97]

Unfortunately, --include-ignored fails due to a handful of ignored illustratory doc examples that don't build

And unfortunately the rustdoc team isn't very open to fixing this for some reason. The interim solution is to specify which tests to include manually, using e.g. smth like test -- --ignored exhaustion_limits.

[tomtau]

@CAD97 ok, thanks for the context. Yes, we can then keep it ignored with a separate step to run -- --ignored ... for the moment then.

[tomtau]

@NoahTheDuke @CAD97 ok to merge this?

[CAD97]

Lgtm now