Which test? (which source code reproduces this?)

/cc @josharian @davecheney

Probably this: e6f9f39

@martisch

I confirm that the offending commit is e6f9f39.

Thanks for confirming. @dsnet, would you please revert that commit.

On Thu, Sep 1, 2016 at 9:11 AM, Joe Tsai notifications@github.com wrote:

I confirm that the offending commit is e6f9f39
e6f9f39
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16940 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA1R9gUyJeOkqU3MTirlmtngONXQlks5qlgoegaJpZM4JyIc4
.

How urgent is this, @dsnet? Can we try rolling forward?

AFK but my guess from my recollection of that CL is that the error stems from something like make([]T, n) where n is a named int type.

Not urgent. It was 1 build failure out of many thousands (passing).

I should also note that I'm discovering these issues from work intended to discover bugs earlier on in the development cycle.

I would prefer to continue the practice of reverting changes rather than
trying to muscle through.

On Thu, Sep 1, 2016 at 10:55 AM, Joe Tsai notifications@github.com wrote:

Not urgent. It was 1 build failure out of many thousands.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16940 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_48GV_J93Zl5J8PIKeVMVNWuXwkks5qliKCgaJpZM4JyIc4
.

Reproduction:

package src

func f(n T) []byte { return make([]byte, 0, T(0i)) }

type T complex64

Will send a fix tomorrow if @martisch doesn't beat me to it.

As for "muscling through", new code will frequently introduce bugs. Reverting on every single bug, during the open dev period, will add a lot of overhead. I am all for reverting when it's during the freeze, or it causes significant breakage that might impede other developers or cause unnoticed further build breakage, or the bug is subtle or unknown and might take a long time to track down, etc. This is a small bug with a minor impact and a minor fix. Let's just fix it.

It was 1 build failure out of many thousands.

Ouch.

I'm fine rolling forward here if the fix is known and everybody can work and build.golang.org isn't all red and impeding workflows.

This just broke on some internal Google code on a test run of tip Go, not affecting anybody, so yay... @dsnet's early testing of Go 1.8 is already bearing fruit.

Working on the fix and new test cases.

CC me on the fix and I'll test the change on the failing test case.

CL https://golang.org/cl/28301 mentions this issue.

@dsnet based on Robert's comment in #16949, I suspect that the compiler is soon going to reject your test case.