Staticcheck 2017.2 Release Notes

Introduction to staticcheck 2017.2

The 2017.2 release of the staticcheck suite of tools focuses on reducing friction – fewer false positives, more tools for suppressing unwanted output, and JSON output for easier integration with other tools.

New features

Linter directives for ignoring problems

In the past, the only ways to ignore reported problems was by using the -ignore flag. This led to overreaching ignore rules which weren't maintained regularly. Now, //lint:ignore and //lint:file-ignore comments can be used to ignore problems, either on specific lines or file-wide. A full description of these directives, their syntax and their behavior can be found in the documentation.

A related change adds the -show-ignored command line flag, which outputs problems that would otherwise be ignored by directives. This is primarily of use with the JSON output format, for custom front ends.

Output formats

All staticcheck tools now support multiple output formats, selectable with the -f flag.

Currently, two formats are supported. The first format is text, which is the default and uses the existing terminal output format. The other is json, which emits JSON. The output is a stream of objects, allowing for a future streaming output mode. Each object uses the following example schema:

{
  "checker": "staticcheck",
  "code": "SA4006",
  "location": {
    "file": "/usr/lib/go/src/database/sql/sql_test.go",
    "line": 2701,
    "column": 5
  },
  "message": "this value of err is never used",
  "ignored": false
}

Control over the exit code of megacheck

Megacheck, the tool for running multiple checkers at once, now has per checker flags for controlling the overall exit code. Previously, megacheck would exit non-zero if any checker found a problem. Now it is possible to configure for each checker whether it should cause a non-zero exit, by using the -<checker>.exit-non-zero flags. This flag defaults to false for gosimple and to true for the other checkers.

Changes to checks

Support for NoCopy in unused

The unused tool now understands NoCopy sentinel types. The NoCopy type, which is canonically a struct with no fields and only a single, empty Lock method, can be used to mark structs as not safe for copying. By declaring a field of this type, go vet will complain when it sees instances of the struct being copied. In the past, unused marked these fields as unused, now it ignores them.

Detection of deprecated identifiers

SA1019 now correctly identifies deprecated methods, in addition to fields and package-level objects. Additionally, staticcheck now keeps track of when each identifier in the Go standard library was deprecated, so that using -go <version> can correctly ignore deprecation warnings that don't apply to the targeted Go version.

Other

  • SA4017 no longer reports pure functions that are stubs – functions that immediately panic or return a constant.
  • SA5007 no longer flags infinite recursion when the function call is spawned as a new goroutine.
  • SA6002 now recognizes that unsafe.Pointer is a pointer type.
  • S1005 no longer suggests for range when targeting a version older than Go 1.4.
  • S1026 has been removed. In some rare instances, copying a string is necessary, and all common ways of doing this were incorrectly flagged by the check.

Other changes

  • The -ignore flag now supports ignoring checks in all packages, by using * as the path.
  • //line directives are now being ignored when reporting problems. That is, problems will always be reported for the actual position in the Go files they occur.
  • From now on, only the first compilation error encountered will be reported. The tools expect to be run on valid Go code and there was little (if any) value in reporting all compilation errors encountered, especially because simple errors can lead to many follow-up errors.

Staticcheck 2017.2.1 Release Notes

The 2017.2.1 release of the staticcheck suite of tools is the first bug fix release, fixing one bug.

Fixed bugs

  • Staticcheck 2017.2 made the detection of deprecated objects Go-version aware. Unfortunately, this only worked correctly for fields and methods, but not package-level objects. This release fixes that.