-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Eagerly collect mono items for non-generic closures #135314
Conversation
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like -Clink-dead-code
will enable eager collection as well but that seems entirely reasonable to me.
@bors r+ |
Does it trigger eager collection of closures too? |
I thought so since it triggers use of rust/compiler/rustc_monomorphize/src/partitioning.rs Lines 1118 to 1141 in 336209e
|
…iaskrgr Rollup of 4 pull requests Successful merges: - rust-lang#134030 (add `-Zmin-function-alignment`) - rust-lang#134776 (Avoid ICE: Account for `for<'a>` types when checking for non-structural type in constant as pattern) - rust-lang#135205 (Rename `BitSet` to `DenseBitSet`) - rust-lang#135314 (Eagerly collect mono items for non-generic closures) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#135314 - compiler-errors:eagerly-mono-closures, r=wesleywiser Eagerly collect mono items for non-generic closures This allows users to use `-Zprint-mono-items=eager` to eagerly monomorphize closures and coroutine bodies, in case they want to inspect the LLVM or ASM for those items. `-Zprint-mono-items`, which used to be called `-Zprint-trans-items`, was originally added in rust-lang#30900: > Eager mode is meant to be used in conjunction with incremental compilation > where a stable set of translation items is more important than a minimal > one. Thus, eager mode will instantiate drop-glue for every drop-able type > in the crate, even of no drop call for that type exists (yet). It will > also instantiate default implementations of trait methods, something that > otherwise is only done on demand. Although it remains an unstable option, its purpose has somewhat expanded since then, and as far as I can tell it's generally useful for cases when you want to monomorphize as many items as possible, even if they're unreachable. Specifically, it's useful for debugging since you can look at the codegen'd body of a function, since we don't emit items that are not reachable in monomorphization. And even more specifically, it would be very to monomorphize the coroutine body of an async fn, since those you can't easily call those without a runtime. This PR enables this usecase since we now monomorphize `DefKind::Closure`.
This allows users to use
-Zprint-mono-items=eager
to eagerly monomorphize closures and coroutine bodies, in case they want to inspect the LLVM or ASM for those items.-Zprint-mono-items
, which used to be called-Zprint-trans-items
, was originally added in #30900:Although it remains an unstable option, its purpose has somewhat expanded since then, and as far as I can tell it's generally useful for cases when you want to monomorphize as many items as possible, even if they're unreachable. Specifically, it's useful for debugging since you can look at the codegen'd body of a function, since we don't emit items that are not reachable in monomorphization.
And even more specifically, it would be very to monomorphize the coroutine body of an async fn, since those you can't easily call those without a runtime. This PR enables this usecase since we now monomorphize
DefKind::Closure
.