On Wed, May 21, 2014 at 10:43 PM, Ian Booth <ian.bo...@canonical.com> wrote:
> We are working to make all juju-core unit tests pass using gccgo. In case you
> didn't already know, there's a common issue which has caused a lot of the
> failures to date. Here's a quick heads up on how to deal with it.
>
> golang-go and gcc-go have different map implementations which results in
> ordering differences, affecting things like range etc (simplistically put,
> gcc-go's map ordering is random whereas currently golang-go is somewhat
> deterministic).
This is changing in the main compiler as well, in Go 1.3:
http://tip.golang.org/doc/go1.3#map
So it'll become even less deterministic there as well.
> Now of course, maps are unordered but what we sometimes do in
> the code is to use a map to hold some data (maybe to eliminate duplicates) and
> then expose that data via a slice or array. If we then do a c.Assert(v1,
> gc.DeepEquals, v2), it will fail on gcc-go, since the order of items in the 2
> slices is different, even though the values are the same.
If that's really the case, it's definitely a bug in gccgo. gocheck's
DeepEquals is implemented in terms of reflect.DeepEqual, which should
not care about the map order. In the standard library of the main
compiler, it clearly does not:
for _, k := range v1.MapKeys() {
if !deepValueEqual(v1.MapIndex(k), v2.MapIndex(k),
visited, depth+1) {
return false
}
}
So gocheck's DeepEquals is fine for such map tests, assuming no bugs
in the underlying implementation.
gustavo @ http://niemeyer.net
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
