Tracking Issue for RFC 3373: Avoid non-local definitions in functions

[traviscross]

This is a tracking issue for the RFC 3373: Avoid non-local definitions in functions (rust-lang/rfcs#3373).

Summary

Add a warn-by-default lint for items inside functions or expressions that implement methods or traits that are visible outside the function or expression.

warning: non-local `impl` definition, they should be avoided as they go against expectation
  --> src/de/impls.rs:21:9
   |
21 | /         impl Visitor for Place<()> {
22 | |             fn null(&mut self) -> Result<()> {
23 | |                 self.out = Some(());
24 | |                 Ok(())
25 | |             }
26 | |         }
   | |_________^
   |
   = help: move this `impl` block outside the of the current associated function `begin`
   = note: an `impl` definition is non-local if it is nested inside an item and neither the type nor the trait are at the same nesting level as the `impl` block
   = note: one exception to the rule are anon-const (`const _: () = { ... }`) at top-level module and anon-const at the same nesting as the trait or type
   = note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>
   = note: `#[warn(non_local_definitions)]` on by default

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 RFC 3373: Avoid non-local definitions in functions #120393
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved questions

• We need a crater run to look at how widespread this pattern is in existing code.
  • Implement RFC 3373: Avoid non-local definitions in functions #120393 (comment)
• Should we flag these definitions in anonymous const items as well, or would that produce unwanted warnings?
  • We do not currently warn on const _: () = { /* .. */ } since the pattern is widely used in the ecosystem, including serde_derive.

Related

• non_local_definitions common issues: impl for &Local, From<Local> for Global, ... #121621 (comment)
• Implement T-types suggested logic for perfect non-local impl detection #122747
• False positive and highly misleading suggestions for the non-local-definitions lint #124396
• non-local-definitions lint fires for impl using private types #125068
• non_local_definitions lint fires for impl Trait for NonLocalType<SomeLocalType>, probably shouldn't #126768
• Switch back non_local_definitions lint to allow-by-default #127015
• Rework non_local_definitions lint to only use a syntactic heuristic #127117

[dtolnay]

I pasted an example of such a warning into the summary above. This issue previously was not appearing in a GitHub search for "non_local_definitions".

[dtolnay]

Should an exception be made for #[fundamental] types?

Filed as #121621.