The golangci-lint being used was quite dated.
This change upgrades to the latest version.
Adds and updates exclusions based on new failures.
Note on revive:
I've included an opt-out for unused parameters for revive
because turning `newThing(required bool)` to `newThing(_ bool)`
is a loss of useful information.
The changes to the Go files are to fix the following issues:
```
camelcase.go:16: File is not `gofmt`-ed with `-s` (gofmt)
config_test.go:50:18: directive `//nolint: gosec` is unused for linter "gosec" (nolintlint)
defaults_test.go:28:25: G601: Implicit memory aliasing in for loop. (gosec)
doc.go:5: File is not `gofmt`-ed with `-s` (gofmt)
kong.go:446:18: directive `//nolint: gosec` is unused for linter "gosec" (nolintlint)
kong_test.go:503:20: G601: Implicit memory aliasing in for loop. (gosec)
model.go:493:10: composites: reflect.ValueError struct literal uses unkeyed fields (govet)
scanner.go:112: File is not `gofmt`-ed with `-s` (gofmt)
```
And to address broken nolint directives reported as follows by
golangci-lint.
```
[.. skipped .. ]
tag.go:65:1: directive `// nolint:gocyclo` should be written without leading space as `//nolint:gocyclo` (nolintlint)
tag.go:206:51: directive `// nolint: gocyclo` should be written without leading space as `//nolint: gocyclo` (nolintlint)
util_test.go:23:43: directive `// nolint: errcheck` should be written without leading space as `//nolint: errcheck` (nolintlint)
util_test.go:51:22: directive `// nolint: errcheck` should be written without leading space as `//nolint: errcheck` (nolintlint)
```
* Move default command validation to build
Move the validation of default commands - checking if a node has
multiple default commands or a default command has children - to the
build phase rather than tracing. These errors are with the structure of
the CLI ast and are detectable before parsing the command line.
Add a couple of tests for some of the default command error cases.
* Disallow positional args on a default command
Do not allow a default command to have positional arguments. The current
check is only for branching args, but the error message implies that
positional args are not allowed either. So add a check for positional
args too, and add a test case for it.
This is breaking change to the API but is unlikely to have ill-effect as
positional args on a default command cannot be used without explicitly
naming the command (i.e. not using it as a default).
* Allow default commands with cmds/args/flags
Allow default commands to have sub-commands, args and flags when tagged
with `default:"withargs"`. This makes specifying the name of the
command on the CLI completely optional as long as the args to that
command are not ambiguous with other commands.
This is useful for situations where the initialisation of some object
should be deferred, eg. when there are distinct "setup" and "use" phases
to a tools lifecycle.
Abhinav Gupta