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 <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
