cmd/compile: 1.7 compiler does not compile program with large complex struct #18920
Comments
ianlancetaylor
changed the title
|
CC @crawshaw |
That's a big name! |
|
I think we should call it 'type name' in error message rather than call it 'name' which makes me feel that was a variable name…? |
|
I don't think this bug only applies to Go1.7, I can reproduce the message on >Go1.8 ie +3a6842a $ go version
go version devel +3a6842a Thu Feb 9 04:13:35 2017 +0000 darwin/amd64so I'll just do a minor retitling of the bug. |
odeke-em
changed the title
|
Ouch... this bug just bit me bad, I am writing a package to generate some structs from a very complicated XSD, is there a work round other then attempting to simplify my structs so they are not so large? And just to clarify, the problem is not the actual Name of my struct right? My name is only 25 characters |
rdvorak
changed the title
|
the workaround is to use 1.6 compiler or if you have large nested structs you can define them separately |
|
Yes this is a real bug that should be fixed at some point. But I would also ask you to consider the readability of your generated code. Go code should be designed for reading, even when made by a machine. Are enormous nested types readable? Would intermediate naming help? (I suspect that almost always, it would.) |
|
In my case the structure is a container for one record of related data and the schema, complexity is not my decision, as it is defined by external data provider- it is real world example. |
|
@crawshaw You are probably right however the code I've generated looks pretty good, it has a bunch of nested structs however they are all only a few fields each, I can probably break them up into structs, I just need to come up with some naming scheme to avoid duplicate struct names :( Is there any information as to why this became a problem in 1.7+ (just curious) |
|
The problem appeared in 1.7 because the type descriptors generated by the compiler were changed to make them smaller (for issue #6853). One of the changes was to store the length of the result of |
|
@ianlancetaylor Thank you for the information |
|
@crawshaw any plans to work on this for 1.9? |
|
Is this issue being worked on for 1.13? |
|
I don't think anyone has anything for 1.13 here. |
|
I hit this in 1.15.5. The compiler can't handle very long structs (~2000 lines). However, |
|
@mbrancato this is a rather old issue referring to an ancient version of the compiler, I think it would be better to open a new issue, complete the template and include a code sample that someone else can use to reproduce the problem. If there are duplicates we (waves generally in the direction of the issue gardening folks) will gladly take care of that. |
gopherbot
added
the
compiler/runtime
|
Not an issue for current versions (1.18/1.19) |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go version go1.7.5 windows/amd64
What operating system and processor architecture are you using (
go env)?Windows Server, Intel
What did you do?
I want to compile a program with large complex struct.
Go 1.7.1, 1.7.5 does not compile the program but the version 1.6.4 does and
it works (Un/Marshalling) perfectly with 1.6.
I have created repo with single main.go file just for this bug report.
https://github.com/rdvorak/largeGoStruct/blob/master/main.go
I had to hash identifiers in the struct because the real structure should not be published.
What did you expect to see?
I want the main.go get compiled.
What did you see instead?
.\main.go:1: internal compiler error: name too long: *struct
.. follows the large struct ...
goroutine 1 [running]:
runtime/debug.Stack(0x0, 0x0, 0x0)
c:/go/src/runtime/debug/stack.go:24 +0x80
cmd/compile/internal/gc.Fatalf(0x911ba1, 0x11, 0xc044fecd20, 0x1, 0x1)
c:/go/src/cmd/compile/internal/gc/subr.go:165 +0x24f
cmd/compile/internal/gc.dnameData(0xc043f2c120, 0x0, 0xc044860000, 0x29331, 0x0, 0x0, 0x0, 0x0, 0x0)
c:/go/src/cmd/compile/internal/gc/reflect.go:515 +0x444
cmd/compile/internal/gc.dname(0xc044860000, 0x29331, 0x0, 0x0, 0x0, 0xc044860000, 0x29331)
c:/go/src/cmd/compile/internal/gc/reflect.go:583 +0x1c8
cmd/compile/internal/gc.dcommontype(0xc042b54000, 0x28, 0xc0426e6a50, 0x9043ff)
c:/go/src/cmd/compile/internal/gc/reflect.go:911 +0x4cb
cmd/compile/internal/gc.dtypesym(0xc0426e6a50, 0xc0426e6a50)
c:/go/src/cmd/compile/internal/gc/reflect.go:1300 +0xef1
cmd/compile/internal/gc.dtypesym(0xc0427306e0, 0xc0426c10a0)
c:/go/src/cmd/compile/internal/gc/reflect.go:1284 +0xd3e
cmd/compile/internal/gc.dtypesym(0xc0426e69b0, 0xc042732380)
c:/go/src/cmd/compile/internal/gc/reflect.go:1296 +0xe98
cmd/compile/internal/gc.dumptypestructs()
c:/go/src/cmd/compile/internal/gc/reflect.go:1369 +0xd3
cmd/compile/internal/gc.dumpobj1(0xc0420440c0, 0x3a, 0x3)
c:/go/src/cmd/compile/internal/gc/obj.go:133 +0x566
cmd/compile/internal/gc.dumpobj()
c:/go/src/cmd/compile/internal/gc/obj.go:45 +0x59
cmd/compile/internal/gc.Main()
c:/go/src/cmd/compile/internal/gc/main.go:490 +0x1aa6
cmd/compile/internal/amd64.Main()
c:/go/src/cmd/compile/internal/amd64/galign.go:93 +0x301
main.main()
c:/go/src/cmd/compile/main.go:33 +0x2aa
The text was updated successfully, but these errors were encountered: