shutej / gomock

Automatically exported from code.google.com/p/gomock
Apache License 2.0
0 stars 0 forks source link

mockgen cannot mock interfaces with embedded interfaces #2

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
When running mockgen on the net.go file part of the standard library, I receive 
an unpleasant error. After some exploration, I determined that it fails on the 
net.Error interface (mockgen successfully runs on the attached file)

areece@areece-laptop:~$ mockgen --source=go/src/pkg/net/net.go 
panic: interface conversion: ast.Expr is *ast.SelectorExpr, not *ast.FuncType

goroutine 1 [running]:
main.(*generator).ScanImports(0x5ccebc, 0x1870e8c0, 0x0)
    /home/areece/go/src/pkg/gomock.googlecode.com/hg/mockgen/mockgen.go:237 +0x734
main.main()
    /home/areece/go/src/pkg/gomock.googlecode.com/hg/mockgen/mockgen.go:82 +0x4ca

goroutine 2 [chan send]:
main._func_001(0x18700db8, 0x18700dc8, 0x0)
    /home/areece/go/src/pkg/gomock.googlecode.com/hg/mockgen/mockgen.go:146 +0x2da
created by main.iterInterfaces
    /home/areece/go/src/pkg/gomock.googlecode.com/hg/mockgen/mockgen.go:150 +0xa8

What version of the product are you using? On what operating system?
Ubuntu 10.04

areece@areece-laptop:~/go$ hg summary
parent: 9652:c9da4512c385 tip
 weekly.html: remove note about exp/template -> template move.
branch: default
commit: (clean)
update: (current)

Original issue reported on code.google.com by awre...@gmail.com on 15 Sep 2011 at 6:04

Attachments:

GoogleCodeExporter commented 9 years ago
In my clone of the gomock library, I have a commit that prevents gomock from 
crashing. However, this doesn't actually fix the issue (the net.Error interface 
is generated but has none of the required methods).

http://code.google.com/r/awreece-gomock/source/detail?r=48767b9189525ef7cb090b37
60b06e8f42abdff5

Original comment by awre...@gmail.com on 15 Sep 2011 at 6:27

GoogleCodeExporter commented 9 years ago
I confirmed that it appears to crash on an inner interface. I'm looking into it 
now.

areece@areece-laptop:~/go/src/pkg/gomock.googlecode.com/hg$ mockgen 
--source=buggy_interface.go 
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x4 pc=0x804a47c]

goroutine 1 [running]:
main.(*generator).ScanImports(0x110ebc, 0x1870e780, 0x0)
    /home/areece/go/src/pkg/gomock.googlecode.com/hg/mockgen/mockgen.go:242 +0x766
main.main()
    /home/areece/go/src/pkg/gomock.googlecode.com/hg/mockgen/mockgen.go:82 +0x4ca

goroutine 2 [runnable]:
main._func_001(0x18700340, 0x18700348, 0x0)
    /home/areece/go/src/pkg/gomock.googlecode.com/hg/mockgen/mockgen.go:146 +0x2da
created by main.iterInterfaces
    /home/areece/go/src/pkg/gomock.googlecode.com/hg/mockgen/mockgen.go:150 +0xa8

Original comment by awre...@gmail.com on 15 Sep 2011 at 6:42

Attachments:

GoogleCodeExporter commented 9 years ago
This is a little tricky. mockgen would in theory have to recursively walk any 
embedded interfaces, which is not possible to do in a purely lexical way. In 
the net.Error case, to produce a mock net.Error we would need to generate the 
Timeout and Temporary methods of it, plus the String method of the embedded 
os.Error; however, when scanning net.go there's no lexical way for mockgen to 
know what os.Error is.

As a stop-gap measure, we can just entirely skip interfaces with embedded 
interfaces.

Original comment by dsymo...@golang.org on 19 Sep 2011 at 12:50

GoogleCodeExporter commented 9 years ago
I think that this is a similar problem to the typechecking problem solved by 
the compiler. I started working on it, and I think the go/types package might 
have a solution - types.Interface.Methods seems to have the values we need. 
http://golang.org/pkg/go/types/#Interface

Original comment by awre...@gmail.com on 19 Sep 2011 at 1:50

GoogleCodeExporter commented 9 years ago
Yes, the type checking will get us there eventually, but it's incomplete, and 
the infrastructure for loading package files is not in play yet.

Original comment by dsymo...@golang.org on 19 Sep 2011 at 1:55

GoogleCodeExporter commented 9 years ago

Original comment by dsymo...@golang.org on 20 Sep 2011 at 4:26

GoogleCodeExporter commented 9 years ago
This issue was closed by revision aca9ae018061.

Original comment by dsymo...@golang.org on 20 Sep 2011 at 4:27

GoogleCodeExporter commented 9 years ago
As I understand, this doesn't actually fix the issue. Could we possibly leave 
this open as a feature request until the issue is actually fixed?

Original comment by awre...@gmail.com on 20 Sep 2011 at 4:56

GoogleCodeExporter commented 9 years ago

Original comment by dsymo...@golang.org on 20 Sep 2011 at 4:59

GoogleCodeExporter commented 9 years ago
This issue was closed by revision 32f2e7cdb6f6.

Original comment by dsymo...@golang.org on 3 Oct 2011 at 9:22

GoogleCodeExporter commented 9 years ago
This issue was closed by revision ac442d1f4f05.

Original comment by dsymo...@golang.org on 23 Jun 2012 at 5:21

GoogleCodeExporter commented 9 years ago
This issue was closed by revision 9e0c25435283.

Original comment by dsymo...@golang.org on 23 Jun 2012 at 5:21