Summary
Loop variables (for i, v := range items) are loop-scoped and should not be instrumented as they cannot cause data races when used within their loop body.
Problem
Currently, our AST-based instrumentor adds race detection calls for all variable accesses, including loop variables like:
for i, v := range items {
race.RaceRead(&i) // False positive - i is loop-local
race.RaceWrite(&v) // False positive - v is loop-local
process(i, v)
}
Impact: ~30% of current false positives come from loop variable instrumentation.
Solution
Add loop variable detection in visitor.go:
- Track loop variable names when entering
*ast.ForStmt and *ast.RangeStmt
- Skip instrumentation for these variables within loop body
- Clean up tracking when exiting loop
Implementation
type instrumentVisitor struct {
// ... existing fields ...
loopVars map[string]bool // Track current loop variables
}
func (v *instrumentVisitor) Visit(node ast.Node) ast.Visitor {
switch n := node.(type) {
case *ast.RangeStmt:
// Track Key and Value identifiers
if key, ok := n.Key.(*ast.Ident); ok {
v.loopVars[key.Name] = true
}
if value, ok := n.Value.(*ast.Ident); ok {
v.loopVars[value.Name] = true
}
// Walk body, then clean up
// ...
case *ast.ForStmt:
// Track Init statement variables
// ...
}
}
func (v *instrumentVisitor) isLoopVariable(ident *ast.Ident) bool {
return v.loopVars[ident.Name]
}
Acceptance Criteria
Estimated Effort
2-3 days
Related
Summary
Loop variables (
for i, v := range items) are loop-scoped and should not be instrumented as they cannot cause data races when used within their loop body.Problem
Currently, our AST-based instrumentor adds race detection calls for all variable accesses, including loop variables like:
Impact: ~30% of current false positives come from loop variable instrumentation.
Solution
Add loop variable detection in
visitor.go:*ast.ForStmtand*ast.RangeStmtImplementation
Acceptance Criteria
iinfor i := 0; i < n; i++) are not instrumentedi, vinfor i, v := range items) are not instrumentedEstimated Effort
2-3 days
Related