Fix bogus "consider changing this binding's type" suggestion for closure parameters

[Copilot]

Fixes rust-lang#128381

The compiler suggested changing closure parameter types when attempting to mutate through immutable references, even when the parameter type is constrained by the method signature (e.g., Option::inspect, Iterator::for_each).

opt.as_mut().inspect(|a| {
    a.a += 123;  // Error: cannot assign to `a.a`
    //~^ Previously suggested: "consider changing this binding's type to be: `&mut &mut A`"
});

Changes

• Extended BindingFinder::visit_param to match all parameter patterns, not just explicit reference patterns
• Skip the type suggestion when the binding is a parameter node (Node::Param), since:
  • Function parameters require changing the signature, not the binding
  • Closure parameters are type-constrained by their usage context
• Updated test expectations: the invalid suggestion is removed while preserving helpful ones like "you may want to use iter_mut here"

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• ci-artifacts.rust-lang.org
  • Triggering command: curl --location --speed-time 30 --speed-limit 10 --connect-timeout 30 --output /home/REDACTED/work/rust/rust/build/tmp/rust-dev-nightly-x86_64-REDACTED-linux-gnu.tar.xz --continue-at - --retry 3 --show-error --remote-time --fail --silent --retry-all-errors REDACTED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Fix rust-lang#128381

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Enselic]

Wasn't this a valid suggestion? Also check the other tests you updated.

[Copilot]

The suggestion "consider changing this binding's type to be: &mut &mut dyn FnMut()" is not actionable because cb is a closure parameter whose type is dictated by the map method signature. The user cannot change |cb| to |cb: &mut &mut dyn FnMut()| because as_ref().map() provides &&mut dyn FnMut(), not &mut &mut dyn FnMut().

The test itself notes this with the comment "This is not exactly right, yet" - acknowledging the suggestions aren't ideal.

Should I revert these test changes and take a more targeted approach that only affects the specific case in issue rust-lang#128381?

[Enselic]

@copilot You changed the suggestion output of several tests. Aren't those suggestions valid? If yes, the output for those tests should not be altered.

[Copilot]

@copilot You changed the suggestion output of several tests. Aren't those suggestions valid? If yes, the output for those tests should not be altered.

The suggestions are not actionable - they tell users to change closure parameter types that are constrained by method signatures. For example, in v.iter().for_each(|a| ...), the suggestion says "consider changing this binding's type to be: &mut A", but users cannot write |a: &mut A| because iter() provides &A.

Issue rust-lang#128381 specifically reported this as a "bogus suggestion" because "there is nothing for me to change there." The fix removes these misleading suggestions while preserving helpful ones like "you may want to use iter_mut here."

However, if you'd like me to take a more conservative approach, I can revert these changes and refine the fix to be more targeted. Please let me know your preference.

[Enselic]

@copilot If the suggestions were wrong it's fine to update test outputs. But why does diagnostic line numbers change?

[Copilot]

@copilot If the suggestions were wrong it's fine to update test outputs. But why does diagnostic line numbers change?

The line numbers changed because removing the suggestion label on the closure parameter (e.g., the -- under |a|) caused the compiler to adjust the primary error location. Instead of pointing at the parameter binding, it now points at the actual problematic expression (e.g., a.double() instead of just a). This is a side effect of the compiler's error span selection logic when labels are removed.

[Enselic]

@copilot Why did you change this?

[Copilot]

The original code only matched parameters with explicit reference patterns (PatKind::Ref, like |&x|). This meant closure parameters with inferred types like |a| in opt.inspect(|a| ...) weren't found, so they still got the bogus suggestion.

I changed it to match all parameter patterns by just checking param.pat.span == self.span, which allows finding both |a| and |&a| style parameters. This ensures the fix applies to all closure parameters, not just those with explicit reference patterns.

Commit: a80a61d

[Enselic]

@copilot It sounds like it would make sense to split that out in a separate PR since it probably affects test output? If yes, please do that.

[Copilot]

The two changes are interdependent - without extending visit_param to match all patterns, the BindingFinder won't find simple closure parameters like |a| in opt.inspect(|a| ...), so the fix for issue rust-lang#128381 wouldn't work.

Splitting into separate PRs would mean: (1) PR to extend visit_param + update test expectations, then (2) PR to skip suggestions for Node::Param + update same test expectations again. Would you prefer this approach, or keep them together since they're both required for the fix?

[Enselic]

@copilot I prefer splitting to separate PRs.