The nil dereference in the next few lines doesn't seem
to cause a segmentation fault on Unix, but does seem
to halt the Go compiler.
The following is a test case:
>>>
package main
func mine(int b) int {
return b + 2
}
func main() {
mine()
c = mine()
}
<<<
Without this change only the following is caught:
typecheck.go:3: undefined: b
typecheck.go:4: undefined: b
with it, we catch all the errors:
typecheck.go:3: undefined: b
typecheck.go:4: undefined: b
typecheck.go:10: undefined: c
typecheck.go:10: cannot assign to c .
R=rsc, minux.ma
CC=golang-dev
https://golang.org/cl/
6542060
for(f=t->type; f!=T; f=f->down) {
if(f->etype != TFIELD)
fatal("widstruct: not TFIELD: %lT", f);
+ if(f->type == T)
+ break;
dowidth(f->type);
if(f->type->align > maxalign)
maxalign = f->type->align;
--- /dev/null
+// errorcheck
+
+// Verify that the Go compiler will not
+// die after running into an undefined
+// type in the argument list for a
+// function.
+// Does not compile.
+
+package main
+
+func mine(int b) int { // ERROR "undefined.*b"
+ return b + 2 // ERROR "undefined.*b"
+}
+
+func main() {
+ mine()
+ c = mine() // ERROR "undefined.*c" "cannot assign to c"
+}