Tracking Issue for `large_assignments` lint

[oli-obk]

This is a tracking issue for the implementation of the MCP rust-lang/compiler-team#420
The feature gate for the issue is #![feature(large_assignments)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC (Implement a lint that highlights all moves larger than a configured limit #83519)
• make sure we inform the user properly about the fact that they can change the limit E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
  • this just needs an additional note on the diagnostic informing the user about the current limit and how to change it.
• reduce the noisiness (it's reported multiple times on different parts of an expression, but should only trigger on the innermost/first one) E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
  • this can be done by adding the current span to a Vec on self in https://github.com/oli-obk/rust/blob/85b1c67910dbeede8aabb16bc0c1c09a2fefe8ab/compiler/rustc_mir/src/monomorphize/collector.rs#L784
  • and then, right before https://github.com/oli-obk/rust/blob/85b1c67910dbeede8aabb16bc0c1c09a2fefe8ab/compiler/rustc_mir/src/monomorphize/collector.rs#L760 checking if the current span overlaps with any span in the vec.
• stop linting in box/arc initialization E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate.
• make span point to specific arg when moving large args into functions (large_assignments: Lint on specific large args passed to functions #116520)
• Differentiate between Operand::Move and Operand::Copy, see rustc_monomorphize: Introduce check_fn_args_move_size() #116310 (comment) and https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/arg.20Spans.20for.20TerminatorKind.3A.3ACall.3F/near/393865180
  • large_assignments: Allow moves into functions #120773
• Make sure diagnostics point to correct span when -Zinline-mir is involed. See large_assignments: Unactionable diagnostics with -Zinline-mir #121672
• fix lint duplication with multiple generic instantiations
• Suggest borrow instead of #[allow(...)] if possible
• enable the lint by default with a 4k threshold (Set default move_size_limit to 4kB for large_assignments lint on nightly #115684)
• disable the lint in tests (by default, users can still turn it on) E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate.
• move lint logic out of compiler/rustc_monomorphize/src/collector.rs (we should do this after we enable the lint by default since doing this has a high risk of regressing performance)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Should this threshold be configurable via the command line?
• Should we split lint into multiple size limits lints?

Implementation history

• https://github.com/rust-lang/rust/pull/83519

[leonardo-m]

This seems an useful lint. But is this lint firing when there's a copy larger than X bytes in the source code, or when the compiler optimization passes actually leave a X bytes copy in the binary? In the second is much more useful because modern compilers are supposed to optimize away many copies (see RVO, etc).

[osa1]

Has anyone started working on the implementation yet?

[oli-obk]

The implementation is in #83519

[oli-obk]

or when the compiler optimization passes actually leave a X bytes copy in the binary? In the second is much more useful because modern compilers are supposed to optimize away many copies (see RVO, etc).

It is indeed the second part. We do this doing collection, so after monomorphization, but before LLVM has a chance to do anything. Though I don't believe LLVM does anything useful here.