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

Prevent exponentially large type sizes in tuple_combinations #945

Merged

Conversation

lcnr
Copy link
Contributor

@lcnr lcnr commented May 23, 2024

This slightly improves the performance of cargo build --release on stable, and prevents a hang1 when using the next-generation trait solver -Znext-solver.

Long term such manually optimizations should be unnecessary, but for now it unfortunately requires some manual effort.

Footnotes

  1. it would finish at some point, but the sun will have probably consumed the earth before then

this avoids capturing unused generic parameters, slightly improving
compile times. The performance cost is a lot higher with the
next-generation trait solver which pretty much hangs without this
change.
@lcnr lcnr changed the title Prevent exponential type sizes in tuple_combinations Prevent exponentially large type sizes in tuple_combinations May 23, 2024
Copy link
Member

@Philippe-Cholet Philippe-Cholet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote this fold specialization. It's sad we need such work but it's fine by me.

@Philippe-Cholet Philippe-Cholet added this to the next milestone May 24, 2024
@Philippe-Cholet Philippe-Cholet added this pull request to the merge queue May 24, 2024
Merged via the queue into rust-itertools:master with commit ac8fb03 May 24, 2024
11 checks passed
@lcnr lcnr deleted the prevent-exponential-type-sizes branch May 24, 2024 13:19
@lcnr
Copy link
Contributor Author

lcnr commented May 24, 2024

after fixing rust-lang/rust#125460 the following causes a compiler error before this PR:

use itertools::Itertools;

fn main() {
    (0..7).tuple_combinations().fold(1, |_, (t0, t1, t2, t3, t4, t5, t6, t7)| 1);
}
error: reached the type-length limit while instantiating `<Map<Fuse<std::ops::Range<i32>>, {closure@<... as Iterator>::fold<..., ...>::{closure#0}}> as Iterator>::fold::<..., ...>`
   --> /home/gh-lcnr/rust/library/core/src/iter/adapters/map.rs:125:5
    |
125 | /     fn fold<Acc, G>(self, init: Acc, g: G) -> Acc
126 | |     where
127 | |         G: FnMut(Acc, Self::Item) -> Acc,
    | |_________________________________________^
    |
    = help: consider adding a `#![type_length_limit="1536444"]` attribute to your crate

bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 27, 2024
[DO NOT MERGE] bootstrap with `-Znext-solver=globally`

A revival of rust-lang#124812.

Current status, we're failing in:

- failing in `rustc_next_trait_solver` with 126 instances of the following error
```
error[E0311]: the parameter type `I` may not live long enough
    |
help: consider adding an explicit lifetime bound
   --> compiler/rustc_next_trait_solver/src/solve/trait_goals.rs:624:53
    |
624 ~     fn consider_structural_builtin_unsize_candidates<'a>(
625 ~         ecx: &mut EvalCtxt<'a, D>,
626 |         goal: Goal<I, Self>,
627 ~     ) -> Vec<Candidate<I>> where I: 'a {
```
- `itertools` hangs, we're already encountered this hang in our previous attempt due to large type sizes. I believe that it's simply caused by a missing cache somewhere, potentially in `wf.rs`, but other visitors may also be responsible. See rust-itertools/itertools#945 for more details

### commits

- rust-lang#133501
- rust-lang#133493
- 9456bfe and b21b116 reimplement candidate preference based on rust-lang#132325, not yet a separate PR
- c3ef9cd is a rebased version of rust-lang#125334, unsure whether I actually want to land this PR for now

r? `@ghost`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants