glib.HashTable support

[diamondburned]

Lots of important things need HashTable support, like some very crucial functions in libsecret. Supporting HashTable properly requires accessing a []Type from the XML, which is planned to be implemented like so:

type AnyType struct {
	// Possible variants.
	Type  *Type  `xml:"-"`
	Array *Array `xml:"-"`

	ValueType  *Type  `xml:"-"`
	ValueArray *Array `xml:"-"`
}

var _ xml.Unmarshaler = (*AnyType)(nil)

func (a *AnyType) UnmarshalXML(d *xml.Decoder, start xml.StartElement) error {
	var all struct {
		Types  []*Type  `xml:"http://www.gtk.org/introspection/core/1.0 type"`
		Arrays []*Array `xml:"http://www.gtk.org/introspection/core/1.0 array"`
	}

	if err := d.DecodeElement(&all, &start); err != nil {
		return err
	}

	if len(all.Types) > 0 {
		a.Type = all.Types[0]
	}
	if len(all.Types) > 1 {
		a.ValueType = all.Types[1]
	}

	if len(all.Arrays) > 0 {
		a.Array = all.Arrays[0]
	}
	if len(all.Arrays) > 1 {
		a.ValueArray = all.Arrays[1]
	}

	return nil
}

However, this doesn't work, as the fields are seemingly missing after UnmarshalXML.

Relevant issue: golang/go#20754.

• C to Go conversion
• Go to C conversion
  • map[string]string
  • map[T]T

[diamondburned]

Why is GIR like this?

[diamondburned]

Minimal reproduction of the above issue: https://play.golang.org/p/dGyj03YQHhw

[diamondburned]

This might be caused by AnyType's recursive mess.

A solution might be to flatten the tree: right now, CallableAttrs may have Array | Type, and Array may contain another Type (until nested arrays are supported). Type may only contain other Types.

This flattening might require replacing existing abstraction routines, however, but it should be trivial for the most parts as long as we keep AnyType but detach it away from Type and Array.

[diamondburned]

Issue #23 blocks this issue.