[SR-5337] Improve diagnostic for 'var' in parameter position

[CodaFi]

Previous ID	SR-5337
Radar	None
Original Reporter	@CodaFi
Type	Improvement

Additional Detail from JIRA

Votes	1
Component/s	Compiler
Labels	Improvement, DiagnosticsQoI, StarterBug
Assignee	None
Priority	Medium

md5: df452a4dc52959caff3a154681f76513

Issue Description:

For code that looks like this

func foo(inout x : Int) {}

or

func foo(_ f : (Int) -> Void) {}

foo { (var x) in
  
}

We used to offer to remove the errant 'var' specifier and extract it into a variable in the body of the function/closure. This diagnostic necessitated a compromise in our modeling of parameter declarations that I have removed. In its place, it would be nice to have a diagnostic of similar quality.

Some ideas would be to redo the old diagnostic, but by first "enqueueing" it then emitting the variable into the body of the function/closure after we parse the opening brace/'in' after a parameter list. Or we could simply do what we do for 'inout' and remove the 'var' specifier then assume the user actually wanted 'inout', etc.

[CodaFi]

For reference, this is the commit I removed it in.

[swift-ci]

Comment by Mike Choi (JIRA)

Just so it's clear, do we want the above closure to be diagnosed and fixed to become the following

foo { ( x ) in{{ var x = x }}{{}}}

if we can all agree on the fact that people who use var on a parameter doesn't mean to use inout?