Closed GoogleCodeExporter closed 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
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:
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
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
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
Original comment by dsymo...@golang.org
on 20 Sep 2011 at 4:26
This issue was closed by revision aca9ae018061.
Original comment by dsymo...@golang.org
on 20 Sep 2011 at 4:27
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
Original comment by dsymo...@golang.org
on 20 Sep 2011 at 4:59
This issue was closed by revision 32f2e7cdb6f6.
Original comment by dsymo...@golang.org
on 3 Oct 2011 at 9:22
This issue was closed by revision ac442d1f4f05.
Original comment by dsymo...@golang.org
on 23 Jun 2012 at 5:21
This issue was closed by revision 9e0c25435283.
Original comment by dsymo...@golang.org
on 23 Jun 2012 at 5:21
Original issue reported on code.google.com by
awre...@gmail.com
on 15 Sep 2011 at 6:04Attachments: