Use go.tools/go/types/typemap in go/types->LLVM/runtime type mapping

[axw]

Use go.tools/go/types/typemap in go/types->LLVM/runtime type mapping

[tmc]

Is typemap up to snuff now such that this is doable? (there's a comment saying "When go/types/typemap is ready, we should use that instead.")

[axw]

I think typemap has been usable for a while, but some of the things llgo was doing made it difficult to use (namely recursive types with receivers). Typemap doesn't consider receivers when comparing types; this was what tripped me up initially.

Would you like to look into this? There's another person looking at making changes in this general area, so I'd like to make sure there's no conflicting work.

[elliott5]

Certainly I'm using Typemap successfully, if only in a small way in the following function:

var TypesEncountered typemap.M
var NextTypeID = 0

// as the code generator encounters new types it logs them here, returning a string of the ID for insertion into the code
func LogTypeUse(t types.Type) string {
    r := TypesEncountered.At(t)
    if r != nil {
        return fmt.Sprintf("%d", r)
    }
    TypesEncountered.Set(t, NextTypeID)
    r = NextTypeID
    NextTypeID++
    return fmt.Sprintf("%d", r)
}

[axw]

@elliott5 Is your Haxe thing (does it have a name yet?) generate runtime type descriptors? How are you translating recursive types?

[elliott5]

@axw no name yet I'm afraid for "Haxe thing", but I'm working on it. I have now published a small companion project https://github.com/elliott5/gohaxelib and I'm hoping to get the main project up by the end of January. Having been out of the programming world for 20 years, I'm a complete beginner when it comes to open source, github and the rest. To start with I may just put up a place-holder project, with some blog-type info (like this) to let people know where I'm up to, start some sensible documentation about the project and hopefully attract possible contributors.

If you mean runtime type descriptions for use by the reflect package, as it is not in the core language spec, I've not looked at it yet in detail. When I do it will be keyed on my TypeID (as in the code snippet above) since that is a single reference across the whole program.

A recursive type is just another TypeID at this level. In the translated code, there are no Haxe types or classes generated from types in Go code (other than method function classes), so the issue does not arise (although obviously there are classes like Complex to model language constructs). The data for a Go type is just an array of stuff in Haxe, like any other struct. I did look at taking Go types into Haxe but given the level of incompatibility between the two type systems it was just too difficult to model - so at the moment, everything's an array.

I'm concerned I may not have adequately answered your questions, if not, feel free to ask some more!

[axw]

@elliott5 That makes sense. Yes, I was referring to the descriptors used by reflect (and runtime, for interface type assertions, etc.).

I had asked because in llgo I translate Go types to LLVM types and runtime type descriptors, and wanted to use typemap for that. There was a problem previously due to how I was translating interfaces to LLVM types, as the receiver of function signatures isn't considered by typemap. I'm changing the way they're represented to match gc, so that shouldn't be an issue any longer. Not sure if there are any remaining issues with runtime type descriptors - it's been a while since I looked at it.

[elliott5]

Well done @axw, it sounds like you've got the issues involved well in hand. I'll jump in if I see any other discussions I might be able to help with, but am always glad to help. Were I not trying to get "Haxe thing" off the ground, I'd be a contributor to llgo. As you know, I think llgo is a strategically important project.

[axw]

This is now done in the ssa branch. The issue will be closed when ssa is merged.