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.

[dessalines]

I'm also getting this issue, but with future-utils. Just started happening with rust 1.46.0.

error: reached the type-length limit while instantiating `<futures::future::Ready<std::res...y>::new_service::{{closure}}#0]>`
   --> /home/xxx/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.5/src/future/future/mod.rs:142:5
    |
142 | /     fn map<U, F>(self, f: F) -> Map<Self, F>
143 | |     where
144 | |         F: FnOnce(Self::Output) -> U,
145 | |         Self: Sized,
146 | |     {
147 | |         assert_future::<U, _>(Map::new(self, f))
148 | |     }
    | |_____^
    |
    = note: consider adding a `#![type_length_limit="1471465"]` attribute to your crate

error: aborting due to previous error

[najamelan]

@eddyb I saw you commented on reddit that this check is removed because it generates to many false positives. Could you clarify here? What is the milestone, is this solved for 1.47 or does it need more action?

[link2xt]

Related issue: #54540

[ghost]

Can confirm this bug on stable 1.46.0, reverting to 1.45.2 fixed the issue. How did this get past crater and into stable? Similarly to @helinwang applying the compiler-suggested fix only increases the suggested type_length_limit

[tmandry]

We've seen a further and more recent regression on nightly on Fuchsia, but we should bisect them separately.

[tmandry]

@rustbot ping cleanup

We need to bisect to figure out where this regression occurred.

[rustbot]

Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
instructions for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @AminArria @camelid @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke

[jbg]

Can confirm this bug on stable 1.46.0, reverting to 1.45.2 fixed the issue. How did this get past crater and into stable? Similarly to @helinwang applying the compiler-suggested fix only increases the suggested type_length_limit

I've found that it does eventually reach a type_length_limit where it will compile, but it can take many iterations. Combined with the significant compile-time regression in 1.46.0 this can be quite painful.

[tmandry]

Bisected the issue on Fuchsia to #75443, which was backported to appear in 1.46 and is likely the cause for all the recent regressions people are noticing.

cc @lcnr @nikomatsakis

[tmandry]

As noted above, @eddyb has said we should just get rid of this check. @nikomatsakis I'm curious to hear your thoughts on that.

For reference, here's a change to raise all the limits we needed to in Fuchsia. Some of the limits are quite high (the highest I see is over 18 million). I will say that all of these are in related parts of the code, which tells me there might be a common denominator. I'm not aware of an easy way of finding it if there is, though. And people working in that part of the code will be left with juggling these arbitrary-seeming limits.

The compile fails immediately on hitting one of these errors, and the offending type may not be the biggest one in the compile, creating the really unfortunate experience of updating the limit only to have it fail again. At one point I just started increasing it myself by arbitrary amounts over what the compiler suggested.

[djc]

Can we close either this or #54540, please? It looks like a bunch of work was done here that was already done for the other one. Should just close one of them to prevent further bifurcation.

[tmandry]

Good point. I'll close this one in favor of #54540, which came first.