nishanths/exhaustive

bug: duplicate case is reported

Closed this issue · 4 comments

We are using facebook/ent to generate codes.

It generates the enum field like this:

// AccessControl defines the type for the access_control enum field.
type AccessControl string

// AccessControlAll is the default AccessControl.
const DefaultAccessControl = AccessControlAll

// AccessControl values.
const (
	AccessControlAll       AccessControl = "all"
	AccessControlAny       AccessControl = "any"
	AccessControlAnonymous AccessControl = "anonymous"
)

func (ac AccessControl) String() string {
	return string(ac)
}

// AccessControlValidator is a validator for the "access_control" field enum values. It is called by the builders before save.
func AccessControlValidator(ac AccessControl) error {
	switch ac {
	case AccessControlAll, AccessControlAny, AccessControlAnonymous:
		return nil
	default:
		return fmt.Errorf("permissionpath: invalid enum value for access_control field: %q", ac)
	}
}

And exhaustive reports: missing cases in switch of type AccessControl: DefaultAccessControl, which is a false positive.

Thanks. I agree this is a false positive. I'll see what I can do.

The commits in the branch named duplicate should fix this issue. I will think about the solution a bit more and try to merge it tomorrow.

I've added the fixes to the master branch. There are two relevant changes.

Firstly, the exhaustive program now takes into account the values of the enum members themselves. So, for the example code above, the false positive will no longer be reported. (This only works for values that are explicitly specified, like in the example. Enums defined using iota may continue to report the false positive; edit 11/2021: enums defined using iota will also not report the false positive—related PR #22.)

Secondly, exhaustive now no longer checks switch statements in generated files (see https://golang.org/s/generatedcode for definition of generated file), unless the -check-generated flag is enabled. The rationale is that generated files should be considered correct as generated, and corrections to generated code, if any, should be made in the generator.

If you're using exhaustive as part of golangci-lint, I'll make a pull request there to pull in these changes (and request a version bump to golangci-lint).

golang-ci pull request: golangci/golangci-lint#1449