large_futures might have more useful fix suggestions

[bragov4ik]

I've enabled large_futures lint in one large project I'm working on and I got many matches for this lint. Clippy only suggests t
o Box::pin(...) the futures. However, inspecting the generated future types cargo +nightly rustc --lib -- -Zprint-type-sizes often exposes some large variable held across .await points (in Suspend states) that are often the reason for the futures' sizes.

I think it would be useful to go through the variables stored in future enum variants and report big ones.

I am aware of large_stack_frames lint, but it floods output with lots of other info (including the large futures themselves), which is not useful when performing the optimizations.
Also, I haven't found other discussions about this particular use case.

What do you think? Is this even possible to implement? Is it actually useful?

[bragov4ik]

For illustration:
clippy output (edited):

error: large future with a size of 24200 bytes
  --> <path>
   |
36 |             match function_name(db, client, *session).await {
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider `Box::pin` on it: `Box::pin(function_name(db, client, *session))`
   |
   = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.93.0/index.html#large_futures
   = note: `-D clippy::large-futures` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(clippy::large_futures)]`

from -Zprint-type-sizes:

...
print-type-size     variant `Suspend2`: 24159 bytes
print-type-size         upvar `.session`: 5192 bytes, offset: 0 bytes, alignment: 8 bytes
print-type-size         upvar `.db`: 8 bytes
print-type-size         upvar `.client`: 8 bytes
print-type-size         local `.db`: 8 bytes
print-type-size         local `.session`: 5192 bytes
print-type-size         padding: 2 bytes
print-type-size         local `..coroutine_field8`: 1 bytes, alignment: 1 bytes, type: bool
print-type-size         local `..coroutine_field9`: 1 bytes, type: bool
print-type-size         local `..coroutine_field10`: 1 bytes, type: bool
print-type-size         padding: 3 bytes
print-type-size         local `.__awaitee`: 13744 bytes, alignment: 8 bytes, type: {
...

Here clearly session can be boxed, which would be nice to see in the hint.

[flip1995]

Wouldn't suggesting to Box::pin just the session produce a rustc type error? function_name probably doesn't expect a Box as the 3rd argument, but rather some &Session type. Not sure how auto-deref will work out here.

[bragov4ik]

Oh, I see. The code example is a bit confusing, because session was already Box<...> and deref turned it into a big stack struct.
Here's some playground example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9143624669eb3551e2df23f26f0bd896

Clippy suggests to Box::pin the future, but to me it makes more sense to Box (even without pin?) the my_big variable, as well as accepted big parameter. I'm not sure if it is reasonable in most other contexts though

[flip1995]

I'm still not clear on what a better suggestion would be here.

The code can't be changed to future_to_fix(Box::new(my_big)) or future_to_fix(Box::pin(my_big)) as that is a type error. But when you then try to fix that type error by deref-ing the Box with future_to_fix(*Box::new(my_big)), you're back to square one and Clippy will correctly complain about the future size again.