regression: reached recursion limit while instantiating

[Mark-Simulacrum]

• https://crater-reports.s3.amazonaws.com/beta-1.49-1/beta-2020-11-26/gh/hiratara.toy-linear-type-system/log.txt

Would be great to see if this is expected -- I think we've previously seen some issues with combine, so maybe just an old version.

cc @matthewjasper @nikomatsakis

[dillona]

searched nightlies: from nightly-2020-10-23 to nightly-2020-12-12
regressed nightly: nightly-2020-10-28
searched commits: from fd54259 to 07e968b
regressed commit: a4d30a7

bisected with cargo-bisect-rustc v0.6.0

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

cargo bisect-rustc

[Mark-Simulacrum]

cc @tmiasko -- any idea how #77876 could cause that? It seems quite unexpected to me but maybe I'm missing something

[tmiasko]

Underneath the recursion limit error lies a success story. The combine crate generates a lot of dead code and a new implementation is much better at removing it. The most significant aspect is removal of dead dyn casts, since without them there are fewer codegen items.

The crate has a configured recursion limit 67, which is exactly what is necessary. Since the codegen item collector uses memoization, removal of dyn cast might increase required recursion depth, which after changes it is at 71.

[Mark-Simulacrum]

Hm, and 67 is lower than the default? I am a bit worried at us exposing such low level details, but it sounds like this should be won't fix.

[apiraino]

Discussed on Zulip and removing I-prioritize

[Mark-Simulacrum]

I am inclined to agree that this is not readily fixable. I am not sure whether we made the right call exposing such internal implementation details to end users - it feels like recursion limits are always going to be error prone for people to configure. However, the limit of 67 configured by this crate is below the minimum Rust by default sets (128 currently) so I am not inclined to be too worried.

cc @hirartara as the author of this regressed crate