Re: golang bindings dirty in tree after libxl build

[Nick Rosbrook <rosbrookn@xxxxxxxxx>]

On Fri, Jun 12, 2020 at 8:15 AM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 12/06/2020 12:59, George Dunlap wrote:
> >
> >> On Jun 12, 2020, at 12:00 PM, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> 
> >> wrote:
> >>
> >> Hello,
> >>
> >> I've just done a libxl build and got things such as:
> >>
> >> --- a/tools/golang/xenlight/helpers.gen.go
> >> +++ b/tools/golang/xenlight/helpers.gen.go
> >> @@ -431,14 +431,14 @@ x.Evtch = int(xc.evtch)
> >>  x.Rref = int(xc.rref)
> >>  x.Connection = ChannelConnection(xc.connection)
> >>  switch x.Connection{
> >> -case ChannelConnectionUnknown:
> >> -x.ConnectionUnion = nil
> >>  case ChannelConnectionPty:
> >>  var connectionPty ChannelinfoConnectionUnionPty
> >>  if err := connectionPty.fromC(xc);err != nil {
> >>   return fmt.Errorf("converting field connectionPty: %v", err)
> >>  }
> >>  x.ConnectionUnion = connectionPty
> >> +case ChannelConnectionUnknown:
> >> +x.ConnectionUnion = nil
> >>  case ChannelConnectionSocket:
> >>  x.ConnectionUnion = nil
> >>  default:
> >>
> >> dirty in tree.  They are all case labels, and only their order in the
> >> switch has changed.
> >>
> >> Does the current binding generation rely on the order of entries in a
> >> python dictionary by any chance?
> > Not explicitly, but obviously somewhat implicitly.
> >
> > Is this a python2/3 issue, or would different versions of python within 2/3 
> > end up with different sort orders?
> >
> > If python3 will always put them in the same order, then we might consider 
> > just switching the script to being explicitly python3.  Otherwise, we’ll 
> > probably have to add sorts.
>
> Python 3.6 now guarantees that the insert order of elements will be
> preserved.  Before that, there are no guarantees at all.
>
> It sounds like some sprinkling of sorted() will be needed.

George,

Unless you have a burning desire, I can take care of this patch today
or tomorrow.

-NR