Repository: rust
Issue: Invalid reached the recursion limit error: long types where there are none
Labels: T-compiler,C-bug,I-monomorphization,A-monomorphization

I have encountered the weirdest bug. When I run `cargo build` or `cargo test` on my project, compilation fails with the error

```text
error: reached the recursion limit while instantiating `values::Values::<std::option::Op...e@src/values.rs:189:20: 189:65]>`
   --> src/values.rs:189:9
    |
189 |         result.map(|_, _, val| val.expect("uninitialized value"))
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: `values::Values::<T>::map` defined here
   --> src/values.rs:100:5
    |
100 | /     pub fn map<R, F>(self, mut f: F) -> Values<R>
101 | |         where F: FnMut(Principal, ValueIdx, T) -> R,
    | |____________________________________________________^
    = note: the full type name has been written to '.../target/debug/deps/ex-f9bacf9cb1022b27.long-type.txt'
```

The error mentions long types, but the file mentioned contains the following text:

```text
values::Values::<std::option::Option<PrimitiveValue>>::map::<PrimitiveValue, [closure@src/values.rs:189:20: 189:65]>
```

which doesn't look like an infinite recursion at all. The function in question looks like

```rust
    pub fn map<R, F>(self, mut f: F) -> Values<R>
        where F: FnMut(Party, Idx, T) -> R,
    {
        self.into_iter()
            .map(|(p, idx, val)| (p, idx, f(p, idx, val)))
            .collect()
    }
```

and the type is 

```rust
pub struct Values<T> {
    pub inner: BTreeMap<Party, Vec<T>>,
}
```

None of these hint at any possible infinite recursion.

Even worse, the error doesn't happen with `cargo check`, only when the project is actually built.

Unfortunately, I can't provide an actual example, since the codebase is proprietary and I was unable to minimize the example thus far. Not for the lack of trying, mind you. Changing the body of `Values::map` into `loop {}` immediately removes the error, which just shouldn't reasonably happen since the type signature is unchanged and should be unaffected by the body. If I try to minimize the example by running `rustc -Z unpretty=expanded`, then once I fix compile errors (either enable all features and use nightly, or loopify the offending code) the error doesn't reproduce.

So the only way to minimize the example is to manually dredge through the crates, carefully removing code, when any removal could remove the error :-(

I will try to make a minimal example later. If I ever succeed, I will add it to this report.

The error reproduces on stable, beta and nightly toolchains. I have reproduced in after `cargo clean`, and on a crate extracted into a separate project.

### Meta
<!--
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.
-->

`rustc +stable --version --verbose`:
```
rustc 1.57.0 (f1edd0429 2021-11-29)
binary: rustc
commit-hash: f1edd0429582dd29cccacaf50fd134b05593bd9c
commit-date: 2021-11-29
host: x86_64-unknown-linux-gnu
release: 1.57.0
LLVM version: 13.0.0
```

`rustc +nightly --version --verbose`
```
rustc 1.59.0-nightly (83b15bfe1 2021-12-28)
binary: rustc
commit-hash: 83b15bfe1c15f325bc186ebfe3691b729ed59f2b
commit-date: 2021-12-28
host: x86_64-unknown-linux-gnu
release: 1.59.0-nightly
LLVM version: 13.0.0
```