[THRIFT-3465] Go Code With Complex Const Initializer Compilation Depends On Struct Order

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.9.3
• Fix Version/s: 0.10.0
• Component/s: Go - Compiler
• Labels: golang thrift

Environment

Go 1.4.2
Thrift 0.9.3
Ubuntu Linux 14.04
amd64

• Assignee: Unassigned
• Reporter: Tom Deering
• Created: 01/Dec/15 23:34
• Updated: 03/Apr/16 17:10
• Resolved: 20/Mar/16 21:18

Description

Thrift 0.9.3 generates invalid Go code for the following Thrift file:

namespace go bug
struct Bar {
	1:list<Foo> foos,
}
struct Foo {
	1:string id,
}
const Bar BAR = {
	"foos": [{
		"id": "fooID",
	}]
}

constants.go

func init() {
	BAR = &Bar{
		Foos: []Foo{
			&Foo{
				ID: "fooID",
			}},
	}
}

This is invalid because &Foo is not a Foo. However, if we flip the order in which Foo and Bar are defined, Thrift 0.9.3 gives us valid Go code:

namespace go no_bug
struct Foo {
	1:string id,
}
struct Bar {
	1:list<Foo> foos,
}
const Bar BAR = {
	"foos": [{
		"id": "fooID",
	}]
}

constants.go

func init() {
	BAR = &Bar{
		Foos: []*Foo{
			&Foo{
				ID: "fooID",
			}},
	}
}

The bug appears to manifest only with use-before-def of structs and a complex initializer containing a field that is a list of the used-before-def'd type. Other kinds of constants (eg list<Foo>) do not seem to expose the bug.

Issue Links

• is related to: THRIFT-3705 Go map has incorrect types when used with forward-defined types