Want a tool to do static analysis of Go code

[Eric Johnson]

While I've been working with Go for quite some time now, there's one part of the Java ecosystem that I miss - FindBugs.

Just to give specific examples, here are four coding errors I thought of for which I think it would be neat / useful to have an automated tool scanning the code:

1. SQL statements constructed manually, instead of using parameters that the driver escapes.
2. Call to os.Exit() from a package other than main
3. File opened in a method, but not closed by all code paths. (For example, forgetting to call defer f.Close() ). This equally applies to any other object that expects a call to "Close()".
4. Potentially calling a method with known invalid values - for example - calling a method on a pointer to a structure, when the pointer to the structure is nil, and the method in question assumes it isn't.

So far as I've found, no tool exists to look for all of the above. Go vet is a good start. I don't think it catches #2, but perhaps I should give myself a challenge to add that? Other checks seem more complicated, and not amenable to just walking the AST.

Is there something out there that does this deeper analysis for Go code already?

If no, I started looking at the various other tools, and realized perhaps I should ask here to get an idea of where best to start? Looks like oracle works with the actual types, instead of just a syntax tree. Perhaps that's a starting place? Is it even possible to add to go vet to do deeper analysis like check to make sure that a file gets closed once opened - for all code paths? A brief glance at the go vet code suggests it is mostly looking for simple stuff that can be determined, relatively context free, from the AST. Adding code that determines all the flows through a method could get tricky, and perhaps isn't appropriate for go vet?

Thoughts?

Eric.

[Nate Brennand]

​​
Although it does not cover every situation, Stripe’s safesql works to solve #1.

​

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[adon...@google.com]

Hi Eric,

there is currently no tool for Go that, like FindBugs, uses type and dataflow analysis to catch a wide variety of bug patterns.  The vet tool comes closest; it uses types for some of its checks but is not flow-sensitive, and the number of checks it performs are relatively few and not customizable.

I think a FindBugs tool would be useful, but it is a substantial undertaking, and the Go community is perhaps more averse than the industry average to false positive reports from analysis tools, and is generally indisposed towards decorating source code with lemmas or annotations, though this may change as the community grows.

Let's look at each of the analyses you mention.  In each case there is a trade-off to be made between solving each problem interprocedurally, which yields results that are more precise but often harder to explain to the user, and solving it locally, which yields fewer but simpler true positive reports.

#1 requires a program dependence graph (PDG) if it is to be solved interprocedurally; it can be done locally on the SSA form (see golang.org/x/tools/go/ssa).

#2 requires a callgraph, which you can get today from the golang.org/x/tools/cmd/callgraph tool.

#3 is a typestate analysis.  The "annotalysis" tools for detecting locking inconsistencies in C++ and Java programs are the best example of this approach, and require certain idioms (no bad thing for locking) and annotations of lemmas at function boundaries.  You could build such a tool on top of the SSA representation.

#4 requires interprocedural dataflow analysis.  Detecting whether nil is a legal receiver value is harder than it seems.

I hope that helps,

cheers

alan

[Tong Sun]

Might not be 100% hit, but check out

Program Analysis, from Golang UK Conference 2015

https://www.youtube.com/watch?v=oorX84tBMqo&list=PLDWZ5uzn69ezRJYeWxYNRMYebvf8DerHd

[Henry Adi Sumarto]

Have you checked Alec Thomas' Go Meta Linter? https://github.com/alecthomas/gometalinter