The new version of goimports works 100x faster
with go modules. Also it has some new features:
$ git cherry -v 6c7e314b6563 92cdcd90bf52 | fgrep imports
+ 5bbcdc15656ef390fab5dd6e8daf95354f7171e3 imports: redesign fixImports
+ ee45598d2ff288037f53f9e13ae0b1a6e2165ad5 imports: create named imports for name/path mismatches (again)
+ 4c53570e0460bc32468f75bf9dd71c018d03bfa9 imports: ignore globals in different packages
+ 1d424dbce8dd500e9e449fd3ff9d0668c09e2ae1 imports: clean up customization seam
+ 6a3e9aa2ab7749d72d1006ee484271b4a11f96c2 imports: fix renamed sibling imports
+ 5f4a60f04f23ac48e0665f257413ae3eacf339be imports: fix renamed sibling imports more
+ bbccd8cae4a9a47e0f978e03ff4b5df88a9fde1e imports: use go/packages, support modules
+ d4971274fe382404aee0e8c163af974f2bf738e6 imports: don't remove imports that conflict with globals
Prior to this change the SkipDir runner was not skipping files such as
`foo/bar/baz.go` with a `skip-dir` entry of `foo/bar` when the `run`
command was invoked with an argument of `foo/...`. This is both a
surprising and problematic behavior change.
The pathology was:
1. `shouldPassIssue()` was receiving an input like `foo/bar/baz.go`
2. `shouldPassIssue()` would call `p.getLongestArgRelativeIssuePath()`
which was returning `bar`, not `foo/bar` as expected.
3. The reason for this was because inside of
`getLongestArgRelativeIssuePath()` it was trimming the prefix that
matched the path prefix (e.g. `foo/`).
If you have the file structure:
- foo/bar/baz.go
- bur/bar/baz.go
There is no way to isolate `foo/bar` from `bur/baz` without strictly
controlling both your `skip-dirs` configuration and the arguments to
`run`.
The rest of the logic to skip files that don't match `run`'s argument
is valid, however the regexp should be evaluated based on the
`filepath.Dir()` of the input (e.g. `foo/bar`) and not the truncated
version of the issue's filepath.
Fixes: #301
This change introduces the ability to use the tilde (`~`) character in your
`-c/--config` flag value to expand your home directory. If invoking this via the
command line with `--config ~/.golangci-lint.yaml`, the user's shell expands the
`~` to the home directory. However, if something is invoking the program for
you (like an editor) it may not do the expansion.
Fixes#289
Signed-off-by: Tim Heckman <t@heckman.io>
1. Fix crash if deps of analyzed packages weren't compiled.
2. Print deps typechecking errors
3. Fix all issues filtering because of empty go env GOCACHE for go < 1.10
Use go/packages instead of x/tools/loader: it allows to work
with go modules and speedups loading of packages with the help
of build cache.
A lot of linters became "fast": they are enabled by --fast now and
work in 1-2 seconds. Only unparam, interfacer and megacheck
are "slow" linters now.
Average project is analyzed 20-40% faster than before if all linters are
enabled! If we enable all linters except unparam, interfacer and
megacheck analysis is 10-20x faster!
Motivation: Make it clear that the message is indicating packages
*which do not compile*, rather than packages which *won't be
compiled [for some unknown reason]*.
Add support for the exclude and ignore flags of errcheck.
Note that, this commit depends on golangci/errcheck#1. We need
to merge it first, update vendors and only then merge this one.
1. Rename in a backward compatible way
2. Remove gosec default exclude list because gosec is already disabled
by default.
3. Warn about unmatched linter names in //nolint directives
4. Process linter names in //nolint directives in upper case
5. Disable gosec for golangci-lint in .golangci.yml
Although the FAQ does eventually mention that
--new-from-rev=origin/master is the right way, --help does not and
using --new in CI is a terrible pitfall.
Make --help point users to -new-from-rev=HEAD~ for CI setups.
Also use HEAD~ instead of origin/master, since HEAD~ is more
universally applicable, e.g. if golangci-lint is ran against a release
branch.
lll is using scanner.Scan() to read the file line by line.
scanner.Scan() might fail if the line is longer than bufio.MaxScanTokenSize
In the case where the specified maxLineLen is smaller than bufio.MaxScanTokenSize
we can return this line as a long line instead of returning an error.
The reason for this change is that this case might happen with autogenerated files
The go-bindata tool for instance might generate a file with a very long line.
In this case, as it's a auto generated file, the warning returned by lll will
be ignored.
But if we return a linter error here, and this error happens for an autogenerated
file the error will be discarded (fine), but all the subsequent errors for lll will
be discarded for other files and we'll miss legit error.
