Ensuring tests pass on gccgo

[Ian Booth]

Hi folks

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). 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.

In such cases, we need to ensure that we use jc.SameContents rather than
DeepEquals. By "such cases", that means where we truly only care about the
contents of the data and not the order.

Here's a brief example, a snippet of code taken from a constraints test.

cons := constraints.MustParse(t.cons)
unsupported, err := validator.Validate(cons)
if t.err == "" {
	c.Assert(err, gc.IsNil)
	c.Assert(unsupported, jc.SameContents, t.unsupported)
} else {
	c.Assert(err, gc.ErrorMatches, t.err)
}

Above, "unsupported" is a []string of attribute names. We don't care what order
they are returned in from Validate(), just that the correct values are all
there. So instead of:

c.Assert(unsupported, jc.DeepEquals, t.unsupported)

we needed to change it to:

c.Assert(unsupported, jc.SameContents, t.unsupported)

The need to use SameContents depends on the internal implementation of the code
under test. But as a general rule, if we use SameContents where we are saying
that order of results is not relevant, then we can be sure tests will pass on
gcc-go as well as golang-go.

If unsure, please test on gcc-go using something like:

go test --compiler=gccgo <blah>

We will soon be gating trunk landings based on *both* golang-go and gcc-go
having successful test runs and we'd like it if we didn't introduce more test
failures to fix in the interim.