You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
package main
type S struct{}
func (s *S) Len() int { return 0 }
func (s *S) Foo() { panic("unsupported") }
func foo() {
var s S
for i := 0; i < s.Len(); i++ {
s.Foo()
}
}
Output:
baz.go:13:14: variable in loop condition never changes (SA4008)
We flag the loop because s.Foo panics unconditionally and the loop executes at most once. However, in the real code, the implementation of S differs for Go 1.17 and Go 1.18, with the Go 1.17 implementation being a stub. The loop isn't incorrect. With the stub implementation, Len() returns zero, the loop never executes and the panic never triggers. The loop variable doesn't change, but it isn't expected to. In the real implementation, Len returns arbitrary values, and Foo doesn't panic unconditionally.
The core problem is that of infeasible paths; we're complaining about a combination of conditions that can never occur under real execution.
There are two workarounds:
Try to understand the loop condition, determine that the loop never executes, and don't flag it. That is, only flag loops that execute at least once.
Since this is only a problem with build tags, require the user to make use of the upcoming build matrix and report merging features.
The text was updated successfully, but these errors were encountered:
Input:
Output:
We flag the loop because s.Foo panics unconditionally and the loop executes at most once. However, in the real code, the implementation of
S
differs for Go 1.17 and Go 1.18, with the Go 1.17 implementation being a stub. The loop isn't incorrect. With the stub implementation, Len() returns zero, the loop never executes and the panic never triggers. The loop variable doesn't change, but it isn't expected to. In the real implementation, Len returns arbitrary values, and Foo doesn't panic unconditionally.The core problem is that of infeasible paths; we're complaining about a combination of conditions that can never occur under real execution.
There are two workarounds:
The text was updated successfully, but these errors were encountered: