regression: reached recursion limit

[BoxyUwU]

• https://crater-reports.s3.amazonaws.com/beta-1.79-2/beta-2024-05-11/gh/jwiegley.motoko_parse/log.txt

[INFO] [stdout] error: reached the recursion limit while instantiating `<(&mut combine::parser::sequence::Skip<combine::parser::combinator::Try<combine::parser::error::Expected<..., ...>>, ...>, ..., ...) as Parser<...>>::parse_mode::<...>`
[INFO] [stdout]    --> /opt/rustwide/cargo-home/registry/src/index.crates.io-6f17d22bba15001f/combine-4.6.2/src/parser/combinator.rs:236:15
[INFO] [stdout]     |
[INFO] [stdout] 236 |         match self.0.parse_mode(mode, input, state) {
[INFO] [stdout]     |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[INFO] [stdout]     |

[compiler-errors]

searched nightlies: from nightly-2024-02-15 to nightly-2024-05-17
regressed nightly: nightly-2024-03-22
searched commit range: 1388d7a...0ad927c
regressed commit: df8ac8f

bisected with cargo-bisect-rustc v0.6.8

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start=2024-02-15 

[compiler-errors]

cc @RalfJung, @oli-obk

[RalfJung]

Did this crate previously succeed to build in both debug and release configurations? My suspicion is that debug builds were already broken, and #122568 just made release builds the same, which is the entire intention of that PR.

[lqd]

Did this crate previously succeed to build in both debug and release configurations?

I believe so. It builds on stable in both debug and release, tests pass in both debug in release. But fails to build on beta with the OP.

[RalfJung]

Okay, interesting.

Unfortunately I know nothing about this entire recursion limit stuff. There's this recursion_depth_reset in the collector, no idea what it does. There are hardly any comments.

If the recursion limit is increased, does the crate build again?
I guess it is expected that compiler refactoring can sometimes make a crate that was barely under the recursion limit, go over. Do we have policy for that?

[lqd]

If the recursion limit is increased, does the crate build again?

Yes, I tried e.g. 190, and it worked.

I guess it is expected that compiler refactoring can sometimes make a crate that was barely under the recursion limit, go over. Do we have policy for that?

I don't know but I believe I've seen it happen before yeah. So maybe this is fine, I'm not sure? Let's see what others think.

The slightly annoying part here I guess, is that the error mentions hitting the recursion limit, but in this instance doesn't say how to increase it. (Maybe we only do so if the #![recursion_limit] attribute is present in the source already, and we just add a note to double it.)

[saethlin]

Maybe we only do so if the #![recursion_limit] attribute is present in the source already

I am pretty sure I've been prompted to add the attribute when it's not already in my source

[apiraino]

I'd also like to get a feeling of how wide this change could be for other crates. And if it should be given visibility in the release notes (as a head-up when new stable lands)

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium