@ianlancetaylor

Thanks, but dumping the mangled name is worse, not better.

The right fix is to write a type printing routine, and then use it in a bunch of places. That is not hard, but nobody has done it. Want to try?

cc @paranoiacblack

Sure, I can manage that. For my purpose the mangled name was better because It found the problem. I will look into a better typename function.

h4ck3rm1k3/gcc-1@d51d1f9 here is a first stab at a set of name methods. needs a lot of work to make it perfect.

It is going to need a test suite as well, I suppose the dumper code would be the way to run it on all different types.

maybe you can give me a tip @ianlancetaylor how to get the original package name from the identifier?

Sorry, I'm not sure which kind of identifier you mean. Give me an example.

I think I have it. Basically inside of a give type I would like to get the named_object.name and package information. It seems that I might need access to the gogo object from inside the type. I am studying the code now, and am very impressed by your work to structure the code in C++. Will figure it out. thanks.

I'm not sure if you resolved this or not but you can only get a named object from a named type. Named objects also have package information. For unnamed types, you'll have to do something different. Also I noticed h4ck3rm1k3/gcc-1@d51d1f9#diff-6dfba358043a87274c856db299475389R4071 doesn't seem right to me. ...interface{} isn't the only var args type. Ideally, that would also be "...%s", type->name()

Thanks for your feedback, I will fix that.

I am still working on it a bit. Now I got the compiler bootrstrapped having fun actually programming in go.

I figured out how to get the names and the packages names. Still need more work on this.

my lastest work is here
https://github.com/h4ck3rm1k3/gcc-1/tree/go-dump-name-fix-1

Still need more work. Ideally would like to have a test case that would have a full coverage of the types in it for ast dump.