reached the type-length limit while instantiating `std::thread::LocalKey::<std::syn...e, ()}]>>]], std::vec::Vec<i32>>`

[kpp]

Code

https://github.com/kpp/futures-async-combinators/blob/master/examples/stream.rs

use futures::executor;
use futures_async_combinators::stream::*;

fn main() {
    let stream = iter(1..=3);
    let stream = map(stream, |x| x + 1);
    let stream = map(stream, |x| x * 2);

    let collect_future = collect(stream);
    let collection: Vec<_> = executor::block_on(collect_future);

    assert_eq!(vec![4, 6, 8], collection);
}

On master (commit 4f0ca7b4afec)

Error

error: reached the type-length limit while instantiating `std::thread::LocalKey::<std::syn...e, ()}]>>]], std::vec::Vec<i32>>`
    |
    = note: consider adding a `#![type_length_limit="1085948"]` attribute to your crate

error: aborting due to previous error

error: Could not compile `futures-async-combinators`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Fails with

$ rustc -vV
rustc 1.39.0-nightly (34e82a7b7 2019-09-10)
binary: rustc
commit-hash: 34e82a7b793a6cdd27df762bf46bab8cdc92b14a
commit-date: 2019-09-10
host: x86_64-unknown-linux-gnu
release: 1.39.0-nightly
LLVM version: 9.0

And later (2019-09-10, 2019-09-12, 2019-09-13, 2019-09-14)

Works with

$ rustc -vV
rustc 1.39.0-nightly (0b36e9dea 2019-09-09)
binary: rustc
commit-hash: 0b36e9dea3f2ff25b1d0df2669836c33cce89ae5
commit-date: 2019-09-09
host: x86_64-unknown-linux-gnu
release: 1.39.0-nightly
LLVM version: 9.0

How to reproduce

 cargo build --example stream

[kpp]

Still failing on rustc 1.40.0-nightly (22bc9e1 2019-09-30)

[kpp]

1.39.0-beta.5 is affected too

[realcr]

@kpp : Do you know about a workaround for this issue?
My codebase is stuck on nightly-2019-09-13, and I can not move forward because of the type length bloat. I am surprised that this issue doesn't affect anyone that uses futures!

[kpp]

Do you know about a workaround for this issue?

Sorry, no. You may add #![type_length_limit="N"] and adjust N to please the compiler.

[realcr]

Unfortunately I believe that this bug has just landed on stable (rustc 1.39.0 (4560ea7 2019-11-04)).
My current workaround is to box very often, otherwise the types generated are too big and compilation never completes.

[najamelan]

I just ran into this. I have an integration test that runs fine on tokio runtime, and when I switch it to async-std I get this error.

[najamelan]

I can't reproduce this on rustc 1.43.0-nightly (c20d7ee 2020-03-11) anymore. Stable 1.42 still has the issue...

[kpp]

I can't reproduce this on rustc 1.43.0-nightly (564758c 2020-03-08) either.

[helinwang]

I got error like

error: reached the type-length limit while instantiating `std::intrinsics::drop_in_place::...c::Vec<u8>>}]>}]>>]>, ()}]>>]>))`
   --> /home/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/ptr/mod.rs:177:1
    |
177 | / pub unsafe fn drop_in_place<T: ?Sized>(to_drop: *mut T) {
178 | |     // Code here does not matter - this is replaced by the
179 | |     // real drop glue by the compiler.
180 | |     drop_in_place(to_drop)
181 | | }
    | |_^
    |
    = note: consider adding a `#![type_length_limit="1465124"]` attribute to your crate

I don't believe adding type_length_limit helps, since I added a super big limit in lib.rs and the error persists:

#![type_length_limit = "209715200000000000"]

BTW, my code is aysnc / await heavy.
Changing the function signature from

async fn foo(...) {}

to

fn foo() -> BoxFuture<'static, ()> {

Fixed the problem for me.

[jbg]

I have just started hitting this when I upgraded to 1.46.0 today. Several crates in a large workspace (with heavy use of async/await) started failing to compile with this error (which I've never seen before), usually referring to LocalKey.

The value it suggests for the type_length_limit increases each time I update it to the suggested value, although I did eventually find values that worked. Also, the error message does not specify which crate failed to build, and the filename shown is from std, so when multiple crates fail in a parallel build, you only know the crate name of the first one.