Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: cannot use &autotmp_1621 (type *error) as type *parseError in argument to runtime.assertE2T2 #15602

Closed
bep opened this issue May 8, 2016 · 11 comments

Comments

@bep
Copy link
Contributor

bep commented May 8, 2016

See failed Travis build for Viper:

https://travis-ci.org/spf13/viper/jobs/128640109

github.com/BurntSushi/toml

# github.com/BurntSushi/toml

../../BurntSushi/toml/parse.go:43: cannot use &autotmp_1621 (type *error) as type *parseError in argument to runtime.assertE2T2

Works on 1.4-1.6, fails on Go tip.

See https://github.com/BurntSushi/toml/blob/master/parse.go#L43

@dr2chase
Copy link
Contributor

dr2chase commented May 8, 2016

This worked with Friday's tip (+83676d6) but now fails nicely for me.

@josharian
Copy link
Contributor

That sure suggests 9d7c9b4

@josharian
Copy link
Contributor

cc @mdempsky @tshprecher

@josharian
Copy link
Contributor

Given that the bug that that CL was fixing is not a regression from 1.6 (it was broken in 1.5 and 1.6), and given Russ's instructions for the code freeze, I suggest we re-open that issue, roll back the buggy fix, add a test case from this issue (closing it in the process), and then re-fix during the 1.8 cycle.

@josharian josharian changed the title cannot use &autotmp_1621 (type *error) as type *parseError in argument to runtime.assertE2T2 cmd/compile: cannot use &autotmp_1621 (type *error) as type *parseError in argument to runtime.assertE2T2 May 8, 2016
@mdempsky
Copy link
Member

mdempsky commented May 8, 2016

Agreed with @josharian. Revert 9d7c9b4 for 1.7, and try again for 1.8.

In retrospect, I suspect the issue is just the temporary variables need to match the RHS's type, not the LHS's type, but I don't want to try to roll forward with the problem now.

Minimal repro:

package p

func f(i interface{}) {
        i, _ = i.(error)
}

@gopherbot
Copy link

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

gopherbot pushed a commit that referenced this issue May 8, 2016
This reverts commit 9d7c9b4.

For #15602.

Change-Id: I464184b05babe4cb8dedab6161efa730cea6ee2d
Reviewed-on: https://go-review.googlesource.com/22930
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@mdempsky
Copy link
Member

mdempsky commented May 8, 2016

Reverted.

@mdempsky mdempsky closed this as completed May 8, 2016
@josharian
Copy link
Contributor

I think this should be closed by a CL adding the minimal reproduction case you identified. That test will pass, and will prevent regression.

@josharian josharian reopened this May 8, 2016
@josharian
Copy link
Contributor

I'll mail such a CL in a bit if you don't beat me to it.

@mdempsky
Copy link
Member

mdempsky commented May 8, 2016

SGTM, go for it.

@gopherbot
Copy link

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

josharian added a commit to josharian/go that referenced this issue May 9, 2016
The problem was fixed by the rollback in CL 22930.
This CL just adds a test to prevent regressions.

Fixes golang#15602

Change-Id: I37453f6e18ca43081266fe7f154c6d63fbaffd9b
@golang golang locked and limited conversation to collaborators May 8, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants