cc @ianlancetaylor, @paranoiacblack

I can take a look at this. Looking at the export data in the object file I see

package lib;
pkgpath test;
type <type 1 "E" = <type 2 "F" <type 3 struct { .test._ <type 4 *<type 5 "M" <type 6 struct { E <type 1>; }>>>; }>>>;
type <type 2>;
type <type 5>;

which as far as I can tell includes the alias 'E' in the right way (assuming that I'm not missing some other problem). I'll poke around on the decode side.

@thanm Please let me know if you want me to look at this - I'm leaving this alone unless I hear otherwise from you.

OK, I am fairly certain this is a bug in the decoder/parser (e.g. gccgoimporter/parser.go).

Here is the type of interest:

type <type 1 "E" = <type 2 "F" <type 3 struct { .test._ <type 4 *<type 5 "M" <type 6 struct { E <type 1>; }>>>; }>>>;

parseNamedType() has code that looks for the '=' token (indicates an alias) in parser.go line 390:

	if p.tok == '=' {
		// type alias
		p.next()
		typ := p.parseType(pkg)  // line 393
		if obj := scope.Lookup(name); obj != nil {
			typ = obj.Type() // use previously imported type
			if typ == nil {
				p.errorf("%v (type alias) used in cycle", obj)
			}
		} else {
			obj = types.NewTypeName(token.NoPos, pkg, name, typ)
			scope.Insert(obj)
		}
		p.typeMap[n] = typ
		return typ
	}

The problem here is that the parseType call on line 393 (marked above) can include types that refer to the index of the alias type -- at that point there won't yet be an entry in typeMap for the type. There has to be some sort of entry in the map for "n" before this call is made.

@griesemer looks like our comments crossed. Yes, if you could please look at it that would be great.

For the record, to get the export data (.gox file) outside blaze, for a file x.go:

gccgo -c x.go
objcopy -j .go_export x.o x.gox

with x.gox containing the export data.

Definitively a parser bug (which was not written with aliases in mind...). But the problem is on line parser.go:206 in parser.parseField, when reading the type for field E of struct M. That type E is not yet set up, and thus is nil.

Change https://golang.org/cl/137857 mentions this issue: go/internal/gccgoimporter: fix updating of "forward declared" types

The fix above is for the std library. This needs to be back-ported to x/tools afterwards.

Change https://golang.org/cl/137995 mentions this issue: go/internal/gccgoimporter: port recent changes from stdlib version