Change:
= help: a `loop` may express intention better if this is on purpose = note: `#[warn(unconditional_recursion)]` on by default <del> error[E0275]: overflow evaluating the requirement `Map<&mut Map<&mut Map<&mut Map<..., ...>, ...>, ...>, ...>: Iterator` </del> <ins> error[E0275]: overflow evaluating the requirement `Map<&mut std::ops::Range<u8>, [closure@$DIR/issue-83150.rs:12:24: 12:27]>: Iterator` </ins> | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`issue_83150`) <ins> = note: required for `&mut Map<&mut std::ops::Range<u8>, [closure@$DIR/issue-83150.rs:12:24: 12:27]>` to implement `Iterator` = note: 65 redundant requirements hidden </ins> = note: required for `&mut Map<&mut Map<&mut Map<&mut Map<&mut Map<&mut Map<&mut Map<..., ...>, ...>, ...>, ...>, ...>, ...>, ...>` to implement `Iterator` = note: the full type name has been written to '$TEST_BUILD_DIR/recursion/issue-83150/issue-83150.long-type-hash.txt'

Discussion:
This was encountered in my project's daily Github Action to compile using the latest Rust nightly. More details can be found here -
We're also hitting this in ICU4X's CI pipeline (which uses combine)
This is likely a duplicate of: This will likely be resolved by: If you wish to verify it fixes this problem, then you may wish to check by compiling with that patch.
This is a duplicate of the currently pinned . Closing to lower signal to noise ratio.

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The notable difference between this issue and others like it (, , ) are that this is happening in 1.67.0 (where the others have it in nightly), and in release mode (where at least one of them only happens in debug mode). Posting this as a separate ticket given these reasons, I hope that's okay. (Tested with v0.7.39) This only happens when building in release mode. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I just confirmed this is also fixed by , but it would be nice to have a reduced test case for this one. label E-needs-mcve
Also possibly related:
Can also confirm that this issue is fixed by , thanks!
needs to be library and release mode label -E-needs-mcve +S-bug-has-mcve
This regressed from 1.66.1 to 1.67.0. label regression-from-stable-to-stable also cc downstream

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Compilation works fine when building WITH .
searched nightlies: from nightly-2023-02-03 to nightly-2023-02-05 regressed nightly: nightly-2023-02-05 searched commit range: regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
: Building a library and the inline attribute are required to reproduce. This example will also ICE on stable, but if you uncomment the last three lines it only ICEs on nighly. So probably only revealed this bug and isn't the root cause of it. label S-bug-has-mcve
label regression-from-stable-to-nightly
I'm also seeing this. in nightly 2/7/23 This date is a mistake. My bad.
cc either or , this seems to be some weirdness in the handling of trivially false bounds (at least the stable variant, the nightly one might be a different root cause) Edit: Oh, I didn't see that there was a fix up already
This ICE also happens on target x8664-unknown-linux-gnu in , however on target x8664-pc-windows-msvc it did not occur.