Private function nobody calls and the compiler does not complain!

[josvazg]

Hi,

I was under the impression that this used to fail to compile:

http://play.golang.org/p/rHD7hUQcZd

Am I mistaken or was something changed in the go compiler?

Go complains if you don't use variables or imports, so it should complain if there is dead code around in the form of private functions that are not called in the package and CAN'T be accessed (cause are private) from other packages.

Was this changed? If so... why?

In the meantime, how can I detect dead code like this, for instance private functions not called in the package?

Thanks in advance,

Jose

[Jan Mercl]

On Wed, Mar 13, 2013 at 1:06 PM, josvazg <jos...@gmail.com> wrote:
> Hi,
>
> I was under the impression that this used to fail to compile:
>
> http://play.golang.org/p/rHD7hUQcZd
>
> Am I mistaken or was something changed in the go compiler?

It's the same for as long as I can remember. IMO, this is permitted,
in contrast to an unused import or variable, because it _may_ become
used when referenced/called from other file of the same package, which
may be included in the build only conditionally. Either through build
tags of by any other means, including for example naming it explicitly
in the compiler's command line.

> In the meantime, how can I detect dead code like this, for instance private
> functions not called in the package?

Probably only using go/{build,parse,ast,types,...}.

-j

[Nate Finch]

This is expected behavior.  It has been discussed somewhat recently, here: https://groups.google.com/forum/#!searchin/golang-nuts/unreachable/golang-nuts/D-mmT10VBEA/nZqQu2Q7qb4J

One of the most common reasons for this kind of code to occur "legally" is if you're compiling for a specific platform and you have a platform-specific function, but don't want to split it out into a whole separate conditionally compiled file.

I'm not sure how easy it would be for the compiler to distinguish between a function that is never called and a function that is only conditionally called.  Someone else might be able to answer that better than me.

As for finding these things, it definitely should be possible to write a tool to parse the code and look for functions that are not exported and are not used.... even if the tool gave false positives for conditionally used functions, it would still be useful.

[josvazg]

Ok thanks!

Now I understand.

But, if the compiler can't complain... Shouldn't "go vet" complain instead?

I mean...

1) If you run "go vet" with no files or restrictions on a package and...

2) There is a private function and...

3) No body calls it in ANY of the FILES in the package...

Shouldn't go vet say something like:

# go vet

somefile.go:32:8: func unused() defined and not used in package localpkg... is it dead code?

(Since if the file is conditionally used, then there is SOME file in which it is called.)

Jose

[josvazg]

I mean this would be very useful cause, when changing package behaviour, some auxiliary functions may get unused and you may forget or don't notice it.

It would be a good practice then to do a go vet to clean-up those functions, if you may.

Jose

[Damian Gryski]

Remy has an implementation of this functionality, although it's not in go vet:

https://github.com/remyoudompheng/go-misc/tree/master/deadcode

Damian

[Rob Pike]

It's issue 4827.