Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
kpp opened this issue Sep 15, 2019 · 22 comments
Labels
A-async-await Area: Async & Await A-typesystem Area: The type system AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. C-bug Category: This is a bug. E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc ICEBreaker-Cleanup-Crew Helping to "clean up" bugs with minimal examples and bisections T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@kpp
Copy link
Contributor

kpp commented Sep 15, 2019

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
Copy link
Contributor Author

kpp commented Oct 1, 2019

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

@Alexendoo Alexendoo added A-typesystem Area: The type system C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 9, 2019
@kpp
Copy link
Contributor Author

kpp commented Oct 10, 2019

1.39.0-beta.5 is affected too

@realcr
Copy link

realcr commented Oct 28, 2019

@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
Copy link
Contributor Author

kpp commented Oct 28, 2019

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
Copy link

realcr commented Nov 14, 2019

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
Copy link
Contributor

najamelan commented Mar 5, 2020

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
Copy link
Contributor

najamelan commented Mar 13, 2020

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

@kpp
Copy link
Contributor Author

kpp commented Mar 14, 2020

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

@helinwang
Copy link

helinwang commented Apr 16, 2020

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
Copy link

jbg commented Aug 28, 2020

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
Copy link

dessalines commented Aug 28, 2020

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
Copy link
Contributor

najamelan commented Aug 29, 2020

@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?

@jonas-schievink jonas-schievink added the A-async-await Area: Async & Await label Aug 29, 2020
@link2xt
Copy link

link2xt commented Aug 29, 2020

Related issue: #54540

@johnmarkwayve
Copy link

johnmarkwayve commented Sep 1, 2020

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 tmandry added the E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc label Sep 1, 2020
@tmandry
Copy link
Contributor

tmandry commented Sep 1, 2020

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

@tmandry
Copy link
Contributor

tmandry commented Sep 1, 2020

@rustbot ping cleanup

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

@rustbot rustbot added the ICEBreaker-Cleanup-Crew Helping to "clean up" bugs with minimal examples and bisections label Sep 1, 2020
@rustbot
Copy link
Collaborator

rustbot commented Sep 1, 2020

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

@tmandry tmandry added this to On deck in wg-async work via automation Sep 1, 2020
@tmandry tmandry added the AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. label Sep 1, 2020
@jbg
Copy link

jbg commented Sep 2, 2020

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
Copy link
Contributor

tmandry commented Sep 4, 2020

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
Copy link
Contributor

tmandry commented Sep 4, 2020

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
Copy link
Contributor

djc commented Sep 4, 2020

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.

nytopop added a commit to nytopop/blip that referenced this issue Sep 6, 2020
This change should be reverted if/when the underlying issue is fixed in
rustc.

related: rust-lang/rust#64496
@tmandry
Copy link
Contributor

tmandry commented Sep 8, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-async-await Area: Async & Await A-typesystem Area: The type system AsyncAwait-Triaged Async-await issues that have been triaged during a working group meeting. C-bug Category: This is a bug. E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc ICEBreaker-Cleanup-Crew Helping to "clean up" bugs with minimal examples and bisections T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests