Prevent exponentially large type sizes in `tuple_combinations` by lcnr · Pull Request #945

Prevent exponentially large type sizes in `tuple_combinations` by lcnr · Pull Request #945 · rust-itertools/itertools

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.

changed the title ~~Prevent exponential type sizes in tuple_combinations~~ Prevent exponentially large type sizes in tuple_combinations

May 23, 2024

lcnr deleted the prevent-exponential-type-sizes branch

May 24, 2024 13:19

lcnr mentioned this pull request

Jul 4, 2024

lcnr mentioned this pull request

Nov 26, 2024

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`