Closed alecthomas closed 6 years ago
@alecthomas This seems to be the result of processing a continue
statement outside a for
statement. It would be nice if you could verify this by providing the code that was passed to ineffassign.
It's easy to fix this on my end. But ideally, code that doesn't compile shouldn't be passed to ineffassign, since it provides checks beyond basic Go validity and depends on it. Can you arrange to run ineffassign conditionally, or (less ideally) ignore it when it panics?
I suppose ineffassign could run its inputs through go/types
and fail early. But that's a somewhat bigger change on my end, as ineffasign currently works on a file-by-file basis. This would also add some unnecessary overhead to the tool, as it doesn't need type information.
That's exactly what it is, yep. It was in this state temporarily due to some in-progress refactoring.
It's easy to fix this on my end. But ideally, code that doesn't compile shouldn't be passed to ineffassign, since it provides checks beyond basic Go validity and depends on it. Can you arrange to run ineffassign conditionally, or (less ideally) ignore it when it panics?
IMO it's not reasonable to panic when the code is ill-formed, but OTOH I agree it's not ideal having to use go/types. I'm not sure what the right course of action is :(
Note that this also occurs when ineffassign is run inside https://github.com/golangci/golangci-lint.
You're right, panicking is not great. I'll fix this case and any others that pop up eventually.