Ensuring tests pass on gccgo

[Ian Booth]

Sorry, I should have made it clearer - we are going to investigate how 
best to do it without significantly slowing down landing time, and 
running in parallel is an option. We'd really like to do it, but if we 
can't then we can make it CI.

On Thu 22 May 2014 18:11:14 EST, John Meinel wrote:
> Please don't actually slow down the time it takes to land code to trunk by
> actually running the tests 2x in a row (and IME gccgo test suite is
> actually more than 1x the time for the golang test suite to run).
> I suppose if you can put them in parallel, but I'd really like to see it
> just be a CI test.
>
> John
> =:->
>
>
>
> On Thu, May 22, 2014 at 5:43 AM, Ian Booth <ian.booth at canonical.com> wrote:
>
>> 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.
>>
>>
>>
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>