For example, "x, _ := a, b" would produce an incorrect CSV that branched to the next statement after evaluating "b", skipping the assignment to 'x'. We already had test coverage for function returns, so I'm reasonably confident this only affects parallel assigns, not destructuring ones like "x, y := f()".
Unlike the old ODASA consistency queries, new consistency queries can have expected results, so there is no need to have special handling of files with expected errors.
Turns out gofmt doesn't actually return 1 when it finds problems, only when it finds source files which don't compile (all of which are now excluded).
This also fixes existing overlooked inconsistencies as a result of this mistake.
The Golang compiler isn't particularly good at spotting paths that don't need a return statement due to a dominating noreturn statement (e.g. os.Exit(1)), so dead return statements are common. We already tried to tolerate some instances of this pattern; this additionally allows 'true' and 'false' literals, and anything of type 'error'.
The carte-blanche for error values aims to accommodate the pattern "abort(); return whateverErrorWouldOtherwiseBeAppropriate();", which is probably preferable to "return nil", a misleading no-error indication.
Method references `x.m` where the receiver of `m` is a pointer implicitly take the address of `x`, so they should be treated much the same as `&x` in terms of data flow. (Ideally we'd make this explicit in the data-flow graph itself, but that's for another PR.)
