Report the use of deprecated stuff

[rakyll]

golint should be able to report cases user is depending on deprecated things. For the case below, it should be able to output "Deprecated: Use Client or Transport in package net/http instead".

$ cat main.go
package main

import (
    "net/http/httputil"
)

func main() {
    httputil.NewClientConn(nil, nil)
}

[dsnet]

For reference: golang/go#10909

[rakyll]

This change will also encourage the use of the same deprecation message formatting in the third party packages.

[stapelberg]

Currently, golint parses and type-checks the file to lint. For type-checking, the gc compiler’s export data is used.

In order to check whether a certain ast.SelectorExpr refers to something deprecated (and what the deprecation message reads), the export data is not sufficient.

Hence, I see two options:

1. Change the export data to include the deprecation message, if any. This increases the size of our export data files. Looking at the standard library, the size increase is about 3 KB in total (grep -r -h 'Deprecated: ' | sed 's,.*Deprecated: ,,g' | sed 's,\s*// ,,g' | wc). If we de-duplicated deprecation messages, the size increase is reduced to about 1.6 KB.
2. Change golint to parse and type-check all packages which are imported directly by the file to lint.

It seems to me that option 1 is overly complicated for what we’re trying to achieve, hence I’d like to implement option 2, even though it makes golint slower (because it needs to do more work). Does that sound reasonable to you?

For option 2, I have a prototype which uses golang.org/x/tools/go/loader and correctly produces a lint warning on your example source code.

I hope to send a pull request within the next few days.

[rakyll]

We want golint to be able to report third party library deprecations as well. I don't think (1) is something we should go with. The ecosystem wants to be able to break APIs but our tools don't do a good job helping the authors communicating these breakages.

I tried to prototype (2) a while ago by modifying the loader package and I personally didn't like the solution, because all of a sudden package loading has to deal with loading dependencies and handling them. But to be fair, I cannot think of any perfect solution right now.

[dominikh]

A couple of thoughts:

1. Is golint really the right place for this check? As I understand it, golint is primarily about style. Is using deprecated identifiers a style issue?
2. staticcheck includes a check for use of deprecated identifiers, so feel free to copy from it. Be warned, though, it depends on some parts of my framework that you'd have to replace.
3. I'd also be concerned with forcing golint to work on entire packages, and type-check all dependencies (which will make it significantly slower) for a single check.
4. @rakyll, what modifications to the loader package did you feel were necessary? go/loader takes care of dependencies, parsing and type-checking for you. It would be trivial to use it to load a package, and its dependencies, from source. Though of course see point 3.

[stapelberg]

I'd also be concerned with forcing golint to work on entire packages, and type-check all dependencies (which will make it significantly slower) for a single check.

Note that using the loader doesn’t force us to work on entire packages. Via the CreatePkgs field in loader.Config, we can specify an individual file in what the loader calls an ad-hoc package.

Also note that we only load and type-check direct dependencies, not all dependencies.

[dominikh]

You can create ad-hoc packages, but if you depend on them to type check without error (which you might not), then the ad-hoc package needs to contain all files of the package.

In order to type-check direct dependencies successfully (which, again, may not be necessary just for the sake of parsing deprecation comments), you need to check dependencies recursively, or build your own version of go/loader that only parses direct dependencies from source, and uses object files for transitive dependencies (which has its own issues.)

[dominikh]

Though I do think you want to load transitive dependencies, to be able to flag deprecated uses in code like this:

import "A"

func fn() {
  A.Fn().Foo()`
}

where A.Fn returns a type from package B (or C or ...) and where Foo is deprecated.

[stapelberg]

Fair point.

The remaining question is about whether the slow-down is acceptable in golint. How do we make that decision?