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: function compiles OK with no return statement #49003

Closed
rogpeppe opened this issue Oct 15, 2021 · 4 comments
Closed

cmd/compile: function compiles OK with no return statement #49003

rogpeppe opened this issue Oct 15, 2021 · 4 comments

Comments

@rogpeppe
Copy link
Contributor

@rogpeppe rogpeppe commented Oct 15, 2021

commit 1cbec68

The following program compiles and runs, but it should complain that there's no return statement in f:

package main

func main() {
	_ = f("")
}

func f(s string) string {
	for range s {
	}
}
@ALTree ALTree added this to the Go1.18 milestone Oct 15, 2021
@randall77
Copy link
Contributor

@randall77 randall77 commented Oct 15, 2021

This is kind of a corner case in the definition of terminating statements.

A "for" statement in which:
there are no "break" statements referring to the "for" statement, and
the loop condition is absent.

Technically that for statement qualifies, so no return after it is needed. There should maybe be an exception for a for range statement?

go1.17 gets this correct (it gives an error).

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 15, 2021

Change https://golang.org/cl/356189 mentions this issue: cmd/compile: make for loops with range statements terminating

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Oct 15, 2021

Nice find!

Loading

@gopherbot gopherbot closed this in 22951fb Oct 15, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Oct 16, 2021

Change https://golang.org/cl/356411 mentions this issue: go/types, types2: add test case for missing return

Loading

gopherbot pushed a commit that referenced this issue Oct 17, 2021
The respective issue was fixed in types2 with CL 356189;
and the problem didn't exist in go/types. This CL simply
adds the test case to the type checkers as well.

For #49003.

Change-Id: Ib50ee8bb0ad21f2916f2b79d4f77593302899a3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/356411
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants