Skip to content

cmd/compile: goto over type/const declarations is erroneously rejected #19088

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.

Sign up for GitHub

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

Jump to bottom
Closed
mdempsky opened this issue Feb 14, 2017 · 7 comments
Closed

cmd/compile: goto over type/const declarations is erroneously rejected #19088

mdempsky opened this issue Feb 14, 2017 · 7 comments
Labels
FrozenDueToAge
Milestone
Go1.9

Comments

@mdempsky
Copy link
Contributor

The Go spec (section "Goto statements") says "Executing the "goto" statement must not cause any variables to come into scope that were not already in scope at the point of the goto."

cmd/compile erroneously rejects this code:

package p

func f() {
	goto out
	type x int
out:
}

with

/tmp/goto.go:4: goto out jumps over declaration of x at /tmp/goto.go:5
@mdempsky mdempsky added this to the Go1.9 milestone Feb 14, 2017
@mdempsky mdempsky self-assigned this Feb 14, 2017
@mdempsky mdempsky changed the title cmd/compile: goto over type/const declarations is valid cmd/compile: goto over type/const declarations is erroneously rejected Feb 14, 2017
@mdempsky mdempsky mentioned this issue Feb 14, 2017
Closed
@mdempsky
Copy link
Contributor Author

Also, go/types accepts the test case.

@dr2chase
Copy link
Contributor

Can't we argue that there is a scope between "out:" and "}" ?

@mdempsky
Copy link
Contributor Author

mdempsky commented Feb 14, 2017 •
edited
Loading

@dr2chase Sorry, I'm not sure I understand your question.

The Go spec forbids gotos that jump over variable declarations such as:

  goto out
  var x int
out:

The issue is that cmd/compile (and gccgo) are also rejecting gotos that jump over type and constant declarations.

@dr2chase
Copy link
Contributor

Ah, oops, never mind.

@griesemer
Copy link
Contributor

Probably not urgent since we lived with this forever. Yet also safe to fix because it will be backward-compatible with existing code (it's lifting a restriction).

@ALTree
Copy link
Member

ALTree commented Feb 15, 2017

Exact dup of #13521 and #8042.

@mdempsky
Copy link
Contributor Author

@ALTree Good finds. Closing as duplicate of #8042.

@golang golang locked and limited conversation to collaborators Feb 15, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.9
Development

No branches or pull requests
5 participants
@mdempsky @dr2chase @ALTree @griesemer @gopherbot