I don't understand this fix. Can you explain it?

If the reason a call doesn't match an expectation is an InOrder then matches will return an error saying that. So why do you believe that f exhaustedNum > 0 && callsErrors.Len() == 0 indicates an ordering issue?

@balshetzer
i thought it was a order issue caused in concurrent invoke.
1.callsErrors.Len() means all method matches
2.exhaustedNum >0 (and expectedNum==0) means the method shouldn't be here, should be in prev position
according two reason,I concluded it was a order issue

Sorry,I couldn't think of another better reason to describe and I thought it was the simplest way to fix it

Some additional info
There is a case where matches will return nil for an ordering error.
e.g.

gomock.InOrder(
  mockFoo.EXPECT().Foo().AnyTimes(),
  mockBar.EXPECT().Bar().AnyTimes(),
  mockBaz.EXPECT().Baz().AnyTimes(),
)

mockFoo.Foo()
mockBar.Bar()
mockFoo.Foo()

This will produce an error message with no additional information following because: (as reported in the issue)

err will always be nil

len(exhausted) will be 1 and len(expected) will be 0

@mjaow are you interested in continuing to work on this PR? If not I'm happy to take it over.

Due to lack of response I am closing out this PR for now. I created #404 to track this issue, assigning it to @cvgw for now. Thank you for reporting this.