possible false negative when assigning a new struct with loop variable to a local var
In the following code, no linter error is raised. Is this case catchable?
var results []Result
for _, v := range iteratee {
r := Result{v: &v}
results = append(results, r)
}
Even public fields are not detected.
type Result struct {
V *string
}
var results []Result
for _, v := range []string{"a", "b", "c"} {
r := Result{V: &v}
results = append(results, r)
}
@kyoh86 plz take a look.
okay, I'll check it out.
@Liooo @windard Sorry for late.
I think I know the cause. But it is too difficult to be fixed by just me.
This linter is checking to see if the pointer of a loop variable is being brought into an external variable, but the check stops at where the "pointer is assigned to a variable". If the destination of the assignment is an external variable, this linter can detect it, but as long as it assigns a local variable in the loop to its counterpart, it is assumed that there is no problem (negative).
A sample for positive:
var results []Result
for _, v := range iteratee {
results = append(results, Result{v: &v})
}
results is an external variable. Assigning to it in one-statement, &v is found.
exportloopref does not track how the value of that local variable is subsequently handled.
In this case, the value placed in the local variable is then assigned (as a result of being appended) to the external variable, which should be detected as a problem.
However, tracking the subsequent treatment of the local variable requires recursively reanalyzing ast once analyzed, which is somewhat expensive and creates the need to track all assignments. Currently, it is possible to analyze the ast in 1-pass, and if multiple analyses are required, such as 2-pass and 3-pass, the process of this linter will become heavier and heavier, so for my part, it is difficult to judge whether it is feasible or not. Of course, it is possible to cover n assignments at most, as in the construction of struct, but I do not have a basis for determining a good upper limit.
CONCLUSIONS:
- If anyone knows how to track such assignments in 1-pass, a Pull-Request would be greatly appreciated.
- If anyone can analyze what kind of performance problems 2-pass, 3-pass, or n-pass would cause, please provide a good upper bound with benchmarks so I can adopt it.
How about provide a strict mode that not allow use any loop var ref. It's simple and easy although violence and rugged.
@Me1onRind If you want it, you can use looppointer instead.
In Go 1.22, it is not a problem