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
typestateint// Internal states used by Writer and Reader.const (
stateIdentifierstate=iotastateHeaderstateEncryptedHeaderstateDatastateFillerstateDone
)
func (r*Reader) xxx() {
switchr.state {
casestateIdentifier:
casestateHeader:
}
}
the exhaustive command will currently (v0.7.11) report:
missing cases in switch of type state: stateData, stateDone, stateEncryptedHeader, stateFiller
Proposal
Change the diagnostic to be the following.
missing cases in switch of type state: stateEncryptedHeader, stateData, stateFiller, stateDone
That is, sort the constant names by AST appearance order (not lexicographical order).
Notes
The AST order makes more natural sense in the context of most programs. For example, in the program above, the AST order is the sequence of states the Reader type goes through when reading its input. The switch statement would be better off listing the cases in that order. I can't think of a counterexample in which using the lexicographical order is more beneficial than the AST order.
The enumMembers type (see file enum.go) already records the list of constant names in AST order. This order can be used during the sort. Implementing the proposal will not introduce a lot of new code.
typeenumMembersstruct {
Names []string// enum member names, AST order// ... other fields elided ...
}
Tests in this repo will need to be adjusted. Tests in the downstream repo golangci-lint, which has a couple of integration tests that assert against exhaustive's diagnostic strings, may also need to be adjusted.
The text was updated successfully, but these errors were encountered:
Background
Given a program:
the
exhaustive
command will currently (v0.7.11) report:Proposal
Change the diagnostic to be the following.
That is, sort the constant names by AST appearance order (not lexicographical order).
Notes
The AST order makes more natural sense in the context of most programs. For example, in the program above, the AST order is the sequence of states the
Reader
type goes through when reading its input. The switch statement would be better off listing the cases in that order. I can't think of a counterexample in which using the lexicographical order is more beneficial than the AST order.The
enumMembers
type (see file enum.go) already records the list of constant names in AST order. This order can be used during the sort. Implementing the proposal will not introduce a lot of new code.Tests in this repo will need to be adjusted. Tests in the downstream repo
golangci-lint
, which has a couple of integration tests that assert againstexhaustive
's diagnostic strings, may also need to be adjusted.The text was updated successfully, but these errors were encountered: