compilerdiagnostics qualitygood first issueimprovement
仓库指标
- 星标
- (69,989 个星标)
- PR 合并指标
- (平均合并 8天 17小时) (30 天内合并 510 个 PR)
描述
| Previous ID | SR-5337 |
| Radar | None |
| Original Reporter | @CodaFi |
| Type | Improvement |
| 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.