remove uses of errors.Is, which requires go1.13, move go1.16/go1.21 tests to separate file

[thaJeztah]

relates to:

• fix: Don't print ErrHelp in ParseAll #443
• add support for Func() and BoolFunc() #426 #429

remove uses of errors.Is, which requires go1.13

Commit 1bf832c introduced the use of
errors.Is, which was added in go1.13, but the go.mod was not
updated to reflect this, causing compile failures on go1.12:

docker run -it --rm -v ./:/pflag -w /pflag golang:1.12 sh -c 'go test -v ./...'
# github.com/spf13/pflag [github.com/spf13/pflag.test]
./flag.go:1190:7: undefined: errors.Is
./flag.go:1219:7: undefined: errors.Is
./bool_func_test.go:86:28: cannot use stdFSet (type *flag.FlagSet) as type BoolFuncFlagSet in argument to runCase:
    *flag.FlagSet does not implement BoolFuncFlagSet (missing BoolFunc method)
...

As the error that is tested will not be wrapped, we can omit the errors.Is,
and instead continue doing a straight comparison.

move Func, BoolFunc, tests as they require go1.21

Commit 69bc3bd added support for Func()
and BoolFunc() to match stdlib. However, the Func method was added in
go1.16.0, and BoolFunc in go1.21.0, so running the tests on older
versions of Go would fail;

docker run -it --rm -v ./:/pflag -w /pflag golang:1.21 sh -c 'go test -v ./...'
# github.com/spf13/pflag [github.com/spf13/pflag.test]
./bool_func_test.go:86:28: cannot use stdFSet (type *flag.FlagSet) as type BoolFuncFlagSet in argument to runCase:
    *flag.FlagSet does not implement BoolFuncFlagSet (missing BoolFunc method)
./bool_func_test.go:113:21: undefined: io.Discard
./bool_func_test.go:116:28: cannot use stdFSet (type *flag.FlagSet) as type BoolFuncFlagSet in argument to runCase:
    *flag.FlagSet does not implement BoolFuncFlagSet (missing BoolFunc method)
./bool_func_test.go:139:7: undefined: errors.Is
./func_test.go:92:28: cannot use stdFSet (type *flag.FlagSet) as type FuncFlagSet in argument to runCase:
    *flag.FlagSet does not implement FuncFlagSet (missing Func method)
./func_test.go:119:21: undefined: io.Discard
./func_test.go:122:28: cannot use stdFSet (type *flag.FlagSet) as type FuncFlagSet in argument to runCase:
    *flag.FlagSet does not implement FuncFlagSet (missing Func method)
./func_test.go:145:7: undefined: errors.Is
./func_test.go:145:7: too many errors
FAIL	github.com/spf13/pflag [build failed]

This patch moves the tests to a separate file that is not built for older
versions of Go.

[thaJeztah]

@tomasaschan PTAL

[tomasaschan]

Given the outrage at recent breaking changes being pushed without moving to v2, I don't think we can bump the required go version before that either. So whatever we have that requires later versions should either be rewritten to work on 1.12, or be moved into flags that can be feature toggled (like you did for the Func/BoolFunc stuff).

I have been meaning to start a conversation about what the path to 2.0 looks like, and what type of changes we want to get in there, but I don't think the right medium for such a discussion is currently available (which is one of the reasons I filed for widening my permissions).

[thaJeztah]

Yeah, the breaking changes are slightly more problematic, but should be solved now with your changes merged (and follow up in #447)

w.r.t. updating the minimum conversion; I think it's fairly reasonable to update to go1.13, which is still very conservative, but if its a big concern; it looks like the only blocker for keeping it at go1.12 is the errors.Is that was added; if errors are not wrapped (which they wouldn't be able to do without %w?), then possibly that could be removed and the version kept at go1.12.

Note that those changes already shipped; this PR is only adjusting the go.mod to reflect that.

[tomasaschan]

Yeah, I think the correct course of action is probably to revert the error.Is usage to == checks - it's only for future-proofing anyway, so it doesn't actually make a difference today. (I'd love to have the test suite run on go 1.12 in CI to not have to keep track of things like this manually!)

Then we can start building a list of things we'd want to do differently in 2.0 (and, perhaps, e.g. explicitly call out that we won't consider bumping required go version a breaking change starting from 2.0). I have a bunch of other things I'd want a more recent go version for too (generics!) but I've decided that all of that has to wait until we've figured out what the path to v2 looks like.

[thaJeztah]

OK 👍 I dropped the first commit, and replaced it with a commit that removes the errors.Is from "production" code. The other uses of errors.Is were in tests that are moved to a Go >= 1.21 file in the second commit.

[tomasaschan]

I wasn't able to make #449 target this PR (probably because it comes from a fork?) but it does verify that this works well on 1.12 too, so I'm gonna go with it. Holding off merging for a bit to see if we want to do a 1.0.10 with only #447 before we merge anything else.

[thaJeztah]

I think both #447 and this one would be good to include in v1.0.10, because this one fixes a bug where the go.mod's requirements don't match the code.

That said; I wouldn't consider either to be critical, or at least, using go1.12 would be a very niche-case (it happens, but usually it would be in some internal codebases in companies maintaining their own LTS Go versions - I know Google itself did so for a long time.

I think it's fine to keep #449 open as draft; you can rebase it once this one's merged, but I can include it in my follow-up to address some linting issues.

[thaJeztah]

Perhaps easier; I cherry-picked your commit in this branch 😄