The _POST declaration in the following snippet gives me the error twitter.go:55:2: don't use ALL_CAPS in Go names; use CamelCase

const (
        _GET  = iota
        _POST = iota
)

Full code: https://github.com/ChimeraCoder/anaconda/blob/master/twitter.go#L53-L57

(Interestingly, _GET does not return an error, though it does if I add any characters to the name - I guess it is special-cased somehow).

I feel that this style (a capitalized constant, prepended with an underscore to prevent it from being exported) should not be considered ALL_CAPS for the purposes of golint - I'm not sure what the alternative CamelCase would be, since this is a single word

I'm filing an issue rather than submitting a pull request in case there is a reason for this style suggestion that I'm not aware of, but as it stands, this error message seems either incorrect or misleadingly named.

Currently, golint complains about a function containing an underscore because the established style for function names is CamelCase. However, the example functions for the testing package sometimes need to have underscores in their names so they're displayed correctly by godoc. Is this worth fixing?

I know there's a TODO item for this

https://github.com/golang/lint/blob/master/golint/golint.go#L116

but after the switch to package mode, it's hard to lint the whole package at one go if tests include both pkg and pkg_test without seeing X is in package pkg, not pkg_test, so IMO this is more of a necessity now.

Modern Java IDEs and Visual Studio can inspect the source code and indicate that boolean expression can be simplified.

It would be nice to see such feature for Go.

Hi, I just tried doing a go get github.com/golang/lint/golint and got the following output on go version go1.1.1 darwin/386

# code.google.com/p/go.tools/go/types
/usr/local/opt/go/src/code.google.com/p/go.tools/go/types/exprstring.go:80: x.Slice3 undefined (type *ast.SliceExpr has no field or method Slice3)
/usr/local/opt/go/src/code.google.com/p/go.tools/go/types/exprstring.go:82: x.Max undefined (type *ast.SliceExpr has no field or method Max)
/usr/local/opt/go/src/code.google.com/p/go.tools/go/types/exprstring.go:83: x.Max undefined (type *ast.SliceExpr has no field or method Max)
/usr/local/opt/go/src/code.google.com/p/go.tools/go/types/initorder.go:64: undefined: heap.Fix```

should omit type uint32 from declaration of var flags; it will be inferred from the right-hand side

This is technically incorrect, as type inference assumes int.

This is similar to #7.

The line in question is this ugly bit of code:

var flags uint32 = syscall.IN_MOVED_TO | syscall.IN_MOVED_FROM |
    syscall.IN_CREATE | syscall.IN_ATTRIB | syscall.IN_MODIFY |
    syscall.IN_MOVE_SELF | syscall.IN_DELETE | syscall.IN_DELETE_SELF

Note: I updated to latest to confirm that this is still an issue, ae65d27.

Hi there. I'm new to Go and am trying to run go lint on a program I'm writing. I'd like clarification on the usage of this library from the command-line.

I've verified the installation went to the directory: go/src/github.com/golang/lint

If I'm in the directory of the code I'm working on (/go/src/github.com/jyaunches/my_program), should I be able to run lint with:

go lint filename.go

??

When I do this, I get:

go: unknown subcommand "lint"

I'm thinking maybe my Go installation isn't completely hooked up properly.. but as I can't find exact usage examples, I thought I would check.

Thanks!

Hi,
I just try to compile your projet, I get the following error :

└─(1080)── go build
# _/home/g179197/perso/lint
./lint.go:734: function ends without a return statement

I believe it's a trivial missing return that can be easily fixed :

diff --git a/lint.go b/lint.go
index b63914b..8cacdc8 100644
--- a/lint.go
+++ b/lint.go
@@ -753,6 +753,7 @@ Loop:
                }
                return false
        }
+       return true
 }

Given

type Interface interface {
    //I don't mention the name.
    F()
}

I would expect

comment on exported interface method  F should be of the form "F ..."

Currently no warning is emitted.

Is it possible that checks for the following constructs should be added to lintMake?

• x := make([]T, 0, 0)
• var x = make([]T, 0)
• var x = make([]T, 0, 0)

Or are they intentionally left out?

It would be useful and consistent with other tools to allow to invoke golint like this:

golint github.com/foo/bar
golint all
golint ./...

The use of "ID" rather than "Id" breaks the rule about abbreviations vs initialisms. "ID" is an initialism for "Identifying Documents", whereas "Id" is an abbreviation for "identifier". Typically, in software engineering, we are referring to the latter.

I understand that in Google and with a lot of Go code, the use of "ID" is considered the correct style. However, there are cases where code cannot follow this convention, such as when avoiding API breakage.

It would be nice to have the ability to disable this rule, such that we continue using golint for some of its better advice, such as documentation.

Golint does not compile if I use go.tools repository 1.3 branch:

# github.com/golang/lint
../../../github.com/golang/lint/lint.go:237: p.typesInfo.TypeOf undefined (type *types.Info has no field or method TypeOf)
../../../github.com/golang/lint/lint.go:243: p.typesInfo.ObjectOf undefined (type *types.Info has no field or method ObjectOf)

It's a problem, because if you use Go 1.3, godoc requires go.tools 1.3 branch:
https://code.google.com/p/go/issues/detail?id=8769

In golint.el, please replace concat "golint " buffer-file-name with combine-and-quote-strings (list "golint" buffer-file-name) to allow file names that need quoting.

I'd like to suggest that log messages should be lowercase similar to error messages, e.g.

log.Println("This is a log message")

should probably be lowercased.

Seems to fit into the style with HTML and URL there already.

golint flags LastInsertId

godrv/driver.go:160:18: func LastInsertId should be LastInsertID

'though I have to implement database/sql/Result interface, which has LastInsertId.
Can I suppress this flag?

Thanks,
GThomas

Running golint on

package main

const kFoo = 1

now gives the error message

foo.go:3:7: const%!(EXTRA string=kFoo, string=foo)

instead of the expected "don't use leading k in Go names"

git bisect tells me the error was introduced in 7430178 , introducing lint problem categorization.

Note that testdata/names.go fails with a similar error

names.go:39:2: const%!(EXTRA string=kLeadingKay, string=leadingKay)

Golint doesn't compile since golang changed repo.

One reason to have an underscore in a variable name is to simulate a decimal in a number, for example

case3_1

Golint suggests a correction to case31 which does not have the same feel. One could argue about the merits of case3_1 as a variable name, but in any event the correction should not be to elide the underscore.

Running golint over code like:

/* Package foo does some stuff

Extra notes about foo that I want in the godoc
*/
package foo

generates the warning:

 package comment should not have leading space

Changing it to

/*Package foo ...

"solves" the problem but looks ugly.

Another workaround is to use

// Package foo does some stufff
/* Extra notes about foo I want in the godoc
*/
package foo

but neither of these are suggested. Perhaps a better comment or check should be "Package comment should start with //"

function lines number > n(maybe 50) or single file lines > n(maybe 500) are bad smell, could you check this?

dougfort@fog:~$ go get github.com/golang/lint/golint

github.com/golang/lint

git/gospideroak/src/github.com/golang/lint/lint.go:883: function ends without a return statement
dougfort@fog:~$

Right now, the linter flags symbols like AutoISO14443_4 as not conforming to the Go naming conventions and suggests removing the underscore. I expect that removing an underscore between numbers is almost never a good suggestion as the underscore usually separates different numbers from one another. I request the linter to not issue a warning for such occurances of underscores.

I have a function
TestMulti(t *testing.T)
in package test

golint says: "func name will be used as test.TestMulti by other packages, and that stutters; consider calling this Multi"

With that signature, the TestMulti function is clearly there to be able to be used by go test. I'm not exactly sure what the recommendation should be (tests should live in the same package as the function they're testing?), but the stutter is not the problem here.

Hi,
Since the last commit (54857da) golint fails with a lot of "undeclared name: someIdentifier" errors.

Some examples:

database.go:14:35: undeclared name: config
dumper.go:51:43: undeclared name: adminSessionsByKey
someFile.go:12:21: undeclared name: dbShared

I'm running golint *.go, but have also tried golint ./; same results.
All the errors seem to be about package-wide globals defined in files other than the one being linted.

Is this a problem in golint, or am I using golint the wrong way?

When using golint at commit 4b1924a I get no errors.

URL github.com/golang/lint/golint isn't exist anymore, so that I can not use go get to install golint.

I would expect golint to also accept package names as arguments, like all the vanilla go test/vet tools do. Files and directories should be accepted as well (just like it is right now).

For example golint ./... should check the current package and all packages below.

Hello!

I'm just wondering if it's valid for Go code to totally ignore values returned from some func.

Example:

func producer() (int, int, error) {
    return 10, 20, errors.New("something")
}

func processor() {
    producer(); // MATCH /error function returns 3 values, 3 ignored/
}

Test case is prepared in commit elgris@6541f24

Cheers!

When invoked from the command line like golint *, it would be useful to see names of the files that had the error. Lines 33 and 40 of golint.go could be changed to, for example:

log.Printf("Failed reading file %v: %v", filename, err)

package main
import (
    "fmt"
)

func main() {
    res := get(3)
    fmt.Println(res)
}

func get(i int) int {
    if f := i * 2; f == 6 {
        return f
    } else {
        return f * 3
    }
}

Running golint displays:

main.go:15:9: if block ends with a return statement, so drop this else and outdent its block

Some error messages use the following prefix T.M: error message where T refers to the receiver type of a method M. Below are some examples from the standard library:

math/big/int.go:507:21: error strings should not be capitalized

func (z *Int) Scan(s fmt.ScanState, ch rune) error {
...
        return errors.New("Int.Scan: invalid verb")

math/big/rat.go:414:21: error strings should not be capitalized

func (z *Rat) Scan(s fmt.ScanState, ch rune) error {
...
        return errors.New("Rat.Scan: invalid verb")

time/time.go:853:27: error strings should not be capitalized

func (t Time) MarshalBinary() ([]byte, error) {
...
            return nil, errors.New("Time.MarshalBinary: zone offset has fractional minute")

What are your thoughts on whitelisting this specific use of capitalized error strings?

I've now been bitten by this about four times in the last couple of weeks; importing a package "package/noun", and then ending up with code that looks something like:

noun := GetCurrentNoun()

if noun == nil {
    noun = noun.DefaultNoun()
}

which fails with a semi-bizarre error message about how DefaultNoun is undefined because type noun.Noun has no field or method DefaultNoun. Careful reading of the error message shows it is correct, but it is surprising.

golint could have a flag to output suggestions in a format that gorename understands. ie:

$ golint -o=golint.ascii .
$ cat golint.ascii
file.go:#123 ID                   // id -> ID
another_file.go:#666 MyFunction   // My_function -> MyFunction

(format of the ASCII file is of course just an example)

alternatively, golint could have a mode to apply directly the changes but that seems a bit against the "suggestions" spirit of golint.

what do you think ?

pubnubMessaging/pubnub.go:34:7: don't use underscores in Go names; const _invalidJson should be _invalidJSON

The _ wasn't removed, and the JSON was capitalized.

A minor issue to be sure, but hey, report early report often ..

I originally prepared a go vet check for this, but came to the conclusion that it was a better fit for go lint. I'm opening this issue as a place to stash the idea + tested go vet code until such time as I (or someone else) adapts it.

Running this check over a recent corpus of public code caught this distribution of ugliness:

    4303 use ! instead of '== false'
    2762 '== true' is extraneous
    2710 use ! instead of '!= true'
    1398 '!= false' is extraneous
      63 '&& false' always yields false
      32 '&& true' is extraneous
      29 '!!' is extraneous
      18 '|| false' is extraneous
      17 '|| true' always yields true

Test cases:

func OhItHurts() {
    var b bool

    _ = b == true  // ERROR "'== true' is extraneous"
    _ = b == false // ERROR "use ! instead of '== false'"
    _ = b != false // ERROR "'!= false' is extraneous"
    _ = b != true  // ERROR "use ! instead of '!= true'"

    _ = b && true  // ERROR "'&& true' is extraneous"
    _ = true && b  // ERROR "'&& true' is extraneous"
    _ = b || false // ERROR "'|| false' is extraneous"

    _ = b && true && b // ERROR "'&& true' is extraneous"
    _ = b && b && true // ERROR "'&& true' is extraneous"
    _ = true && b && b // ERROR "'&& true' is extraneous"

    _ = !!b // ERROR "'!!' is extraneous"
}

func DebugMeNot() {
    var b bool

    _ = b && false // ERROR "'&& false' always yields false"
    _ = b || true  // ERROR "'|| true' always yields true"
    _ = true || b  // ERROR "'|| true' always yields true"
}

Excerpted vet check:

func checkBoolUnaryExpr(f *File, e *ast.UnaryExpr) {
    if e.Op != token.NOT {
        return
    }
    if u, ok := e.X.(*ast.UnaryExpr); ok && u.Op == token.NOT {
        f.Badf(e.Pos(), "'!!' is extraneous")
    }
}

var dual = [token.VAR + 1]token.Token{ // token.VAR+1: issue 7951
    token.LAND: token.LOR,
    token.LOR:  token.LAND,
    token.EQL:  token.NEQ,
    token.NEQ:  token.EQL,
}

func checkBoolBinaryExpr(f *File, e *ast.BinaryExpr) {
    if dual[e.Op] == token.Token(0) { // not a boolean operator
        return
    }

    var tf string
    var op token.Token
    for _, expr := range [...]ast.Expr{e.X, e.Y} {
        if ident, ok := expr.(*ast.Ident); ok {
            switch ident.Name {
            case "false":
                op = dual[e.Op]
                tf = ident.Name
                break
            case "true":
                op = e.Op
                tf = ident.Name
                break
            }
        }
    }

    if tf == "" {
        return
    }

    switch op {
    case token.EQL, token.LAND:
        f.Badf(e.Pos(), "'%s %s' is extraneous", e.Op, tf)
    case token.NEQ:
        f.Badf(e.Pos(), "use ! instead of '%s %s'", e.Op, tf)
    case token.LOR:
        f.Badf(e.Pos(), "'%s %s' always yields %s", e.Op, tf, tf)
    }
}

Note that most of these can be fixed with simple gofmt -r invocations.

ff22a87 causes golint to panic during execution. I tried removing the changes to lint.go in this commit and then golint was able to properly execute without panicking.

Panic output:

$ $HOME/gopath/bin/golint **/*.go
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x58 pc=0x4ea5d5]
goroutine 1 [running]:
runtime.panic(0x6038a0, 0x8a8cc8)
    /home/travis/.gvm/gos/go1.2.2/src/pkg/runtime/panic.c:266 +0xb6
code.google.com/p/go.tools/go/types.(*Info).TypeOf(0xc2103516e0, 0x7f84366b8690, 0xc210202ae0, 0x7, 0x0)
    /home/travis/gopath/src/code.google.com/p/go.tools/go/types/api.go:219 +0x125
github.com/golang/lint.(*pkg).typeOf(0xc2100bc5a0, 0x7f84366b8690, 0xc210202ae0, 0x4, 0x6b33e0)
    /home/travis/gopath/src/github.com/golang/lint/lint.go:231 +0x62
github.com/golang/lint.func·007(0x7f84366cf980, 0xc2101f9aa0, 0x20b36517a00)
    /home/travis/gopath/src/github.com/golang/lint/lint.go:827 +0x4d3
github.com/golang/lint.walker.Visit(0xc21034e2c0, 0x7f84366cf980, 0xc2101f9aa0, 0x456086, 0x0)
    /home/travis/gopath/src/github.com/golang/lint/lint.go:1185 +0x36
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cf980, 0xc2101f9aa0)
    /home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:52 +0x58
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cf710, 0xc210200b00)
    /home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:329 +0x2033
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cfb30, 0xc2101faad0)
    /home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:186 +0x358a
go/ast.walkStmtList(0x7f84366cf6b8, 0xc21034e2c0, 0xc2101ff580, 0x6, 0x8)
    /home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:32 +0x95
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cf4a0, 0xc210205630)
    /home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:224 +0x3e8a
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366cf800, 0xc210205660)
    /home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:342 +0xbf4
go/ast.walkDeclList(0x7f84366cf6b8, 0xc21034e2c0, 0xc210200fc0, 0x4, 0x4)
    /home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:38 +0x95
go/ast.Walk(0x7f84366cf6b8, 0xc21034e2c0, 0x7f84366ca580, 0xc2101ff700)
    /home/travis/.gvm/gos/go1.2.2/src/pkg/go/ast/walk.go:351 +0x2a52
github.com/golang/lint.(*file).walk(0xc210207640, 0xc21034e2c0)
    /home/travis/gopath/src/github.com/golang/lint/lint.go:1161 +0x64
github.com/golang/lint.(*file).lintVarDecls(0xc210207640)
    /home/travis/gopath/src/github.com/golang/lint/lint.go:852 +0x8c
github.com/golang/lint.(*file).lint(0xc210207640)
    /home/travis/gopath/src/github.com/golang/lint/lint.go:145 +0x6d
github.com/golang/lint.(*pkg).lint(0xc2100bc5a0, 0xc2100ad7b0, 0x7fff0d67cd84, 0x12)
    /home/travis/gopath/src/github.com/golang/lint/lint.go:122 +0xb6
github.com/golang/lint.(*Linter).LintFiles(0x7f8436518d38, 0xc21003ab40, 0x7fff0d67cea5, 0x17, 0xc2100a9000, ...)
    /home/travis/gopath/src/github.com/golang/lint/lint.go:79 +0x309
main.lintFiles(0xc21000a010, 0x55, 0x55)
    /home/travis/gopath/src/github.com/golang/lint/golint/golint.go:76 +0x1f1
main.main()
    /home/travis/gopath/src/github.com/golang/lint/golint/golint.go:50 +0x17b

Source: https://travis-ci.org/natebrennand/twiliogo/builds/34879381

Hey there! I hope I'm not just being stupid here.
go version:
go version go1.2.2 darwin/amd64

Running on Yosemite public beta 3.
The results of go get github.com/golang/lint/golint are:

../../src/github.com/golang/lint/lint.go:237: p.typesInfo.TypeOf undefined (type *types.Info has no field or method TypeOf)
../../src/github.com/golang/lint/lint.go:836: f.pkg.typesInfo.ObjectOf undefined (type *types.Info has no field or method ObjectOf)

EDIT

Looks like it might be an issue with my gopath. Hang on.

EDIT

Yep, it was a problem with my GOPATH. I had multiple paths in my gopath, including company tools with a package called types. I think that was causing confusion. Once I set the gopath to a different location go get works just fine.

This should be in the readme... but what's the difference between this and go fmt?

I used to run golint on a directory and subdirectories with golint ..
Currently, it only lints the current directory.

I also tried to run golint ./... but I get:

golint ./...
import "./...": import relative to unknown directory

plese provide emacs hooks like golang provide for save

The $GOPATH variable is defined to be a platform list (ie, on Unix, something with colons in it), so the README instructions fail because the globpath() parameter is a supposed to be a vim string delimiting items with commas.

The closest I've gotten to correct is this:

  if exists("$GOPATH")
    let t=globpath(substitute($GOPATH, ":", ",", "g"), "src/github.com/golang/lint/misc/vim")
    if t != ""
      let &runtimepath.=','.t
    endif
    unlet t
  endif

Perhaps of use.

Trying to make my build fail when golint finds lint, but that's kind of annoying to do right now with golint because it always exits 0.

It seems that vim setup documentation should be updated. Running :Lint produces error, while running :GoLint does the thing.

One example is here: https://skia.googlesource.com/buildbot/+/master/perf/go/db/db.go

golint says:

perf/go/db/db.go:8:2: a blank import should be only in a main or test package, or have a comment justifying it
perf/go/db/db.go:10:2: a blank import should be only in a main or test package, or have a comment justifying it

Would it be possible to relax the comment requirements for constants so they can also include an optional leading article.

Below is a simple example:

package p

// Mod corresponds to a bitfield of modifier key flags.
type Mod int

// Modifier key flags.
const (
    // The ModControl bit is set if one or more Control keys were held down.
    ModControl Mod = 1 << iota
    // The ModShift bit is set if one or more Shift keys were held down.
    ModShift
    // The ModAlt bit is set if one or more Alt keys were held down.
    ModAlt
    // The ModSuper bit is set if one or more Super keys were held down.
    ModSuper
)

Running golint on p gives the following warnings:

p/p.go:8:2: comment on exported const ModControl should be of the form "ModControl ..."
p/p.go:10:2: comment on exported const ModShift should be of the form "ModShift ..."
p/p.go:12:2: comment on exported const ModAlt should be of the form "ModAlt ..."
p/p.go:14:2: comment on exported const ModSuper should be of the form "ModSuper ..."

I tried to use find and xargs with golint but it crashes. If I pass -L 1 to xargs it runs just fine.

ericu@ericu-trusty-ubuntu:~/rtb/src/spiceworks.com/rtb$ find . -type f -name '*.go' | xargs golint
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x58 pc=0x50e064]

goroutine 16 [running]:
runtime.panic(0x657b80, 0x7d76d3)
/home/ericu/builds/go/src/pkg/runtime/panic.c:279 +0xf5
code.google.com/p/go.tools/go/types.(_Info).TypeOf(0xc208bc39f0, 0x7fd71cdcfc70, 0xc208b950c0, 0x0, 0x0)
/home/ericu/rtb/src/code.google.com/p/go.tools/go/types/api.go:219 +0x194
github.com/golang/lint.(_pkg).typeOf(0xc20801af00, 0x7fd71cdcfc70, 0xc208b950c0, 0x0, 0x0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:231 +0x74
github.com/golang/lint.func·007(0x7fd71caf7838, 0xc208b8e870, 0xc208b8b501)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:827 +0x5c2
github.com/golang/lint.walker.Visit(0xc208ce67a0, 0x7fd71caf7838, 0xc208b8e870, 0x0, 0x0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:1185 +0x48
go/ast.Walk(0x7fd71caf7750, 0xc208ce67a0, 0x7fd71caf7838, 0xc208b8e870)
/home/ericu/builds/go/src/pkg/go/ast/walk.go:52 +0x58
go/ast.Walk(0x7fd71caf7750, 0xc208ce67a0, 0x7fd71caf77a8, 0xc208b92c80)
/home/ericu/builds/go/src/pkg/go/ast/walk.go:329 +0x21e0
go/ast.walkDeclList(0x7fd71caf7750, 0xc208ce67a0, 0xc2083b0600, 0x13, 0x20)
/home/ericu/builds/go/src/pkg/go/ast/walk.go:38 +0xd1
go/ast.Walk(0x7fd71caf7750, 0xc208ce67a0, 0x7fd71cdf99d0, 0xc208b74c80)
/home/ericu/builds/go/src/pkg/go/ast/walk.go:351 +0x2cb6
github.com/golang/lint.(_file).walk(0xc208ba0140, 0xc208ce67a0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:1161 +0x82
github.com/golang/lint.(_file).lintVarDecls(0xc208ba0140)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:852 +0x8c
github.com/golang/lint.(_file).lint(0xc208ba0140)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:145 +0x6d
github.com/golang/lint.(_pkg).lint(0xc20801af00, 0x0, 0x0, 0x0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:122 +0xf0
github.com/golang/lint.(*Linter).LintFiles(0xc208dd5c90, 0xc208026ba0, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/ericu/rtb/src/github.com/golang/lint/lint.go:79 +0x3de
main.lintFiles(0xc20800e010, 0x7b, 0x7b)
/home/ericu/rtb/src/github.com/golang/lint/golint/golint.go:76 +0x235
main.main()
/home/ericu/rtb/src/github.com/golang/lint/golint/golint.go:50 +0x183

goroutine 19 [finalizer wait]:
runtime.park(0x4146d0, 0x7dbf90, 0x7daa89)
/home/ericu/builds/go/src/pkg/runtime/proc.c:1369 +0x89
runtime.parkunlock(0x7dbf90, 0x7daa89)
/home/ericu/builds/go/src/pkg/runtime/proc.c:1385 +0x3b
runfinq()
/home/ericu/builds/go/src/pkg/runtime/mgc0.c:2644 +0xcf
runtime.goexit()
/home/ericu/builds/go/src/pkg/runtime/proc.c:1445
ericu@ericu-trusty-ubuntu:~/rtb/src/spiceworks.com/rtb$ find . -type f -name '*.go' | wc -l
123

Hi,

I have this in my ~/.vimrc:

filetype plugin indent on
set rtp+=~/golib/src/github.com/golang/lint/misc/vim

But when I run ':Lint' in a go file vim says:
E492: Not an editor command: Lint

What am I missing?

Thanks!