cmd/compile: check that all n.Val() uses checked for a nil n.Type

[mvdan]

If there was an error in a program related to n, such as the use of an undefined name to declare it, the node may be incomplete. In particular, using n.Val() can cause panics, as is the case of n.Val().Interface().

A recent example: #21988

We should check the compiler to see if there are other instances of n.Val() use without us checking for n.Type == nil (or n.Type != nil). Ideally in an automated manner, as there are more than a hundred .Val() method calls in the gc package.

[mvdan]

/cc @randall77

[gopherbot]

Change https://golang.org/cl/66450 mentions this issue: cmd/compile: fix another invalid switch case panic

[gopherbot]

Change https://golang.org/cl/66690 mentions this issue: cmd/compile: make Node.Val panic if .Type is nil

[mvdan]

Continuing the discussion from https://golang.org/cl/66690, @mdempsky said:

I think the issue is that consttype(n)==0 indicates a weird state: it's an OLITERAL constant that's missing a Val.

An alternative fix for your swt.go changes would be to just change the "consttype(n) < 0" checks to "consttype(n) <= 0".

I'm trying to think whether it even makes sense to distinguish 0 from -1 in consttype's return value. Maybe collapsing them to a single return value would be the real fix here.

A couple of places, one in swt.go and one in const.go, use consttype(n) >= 0. What should we do with those?

Otherwise, all checks are either == x, != x, or < 0.

[mdempsky]

I'm leaning towards:

1. Change consttype to return 0 for nil and non-OLITERAL nodes.
2. Change all of the consttype(n) >= 0 calls to consttype(n) > 0, and consttype(n) < 0 to consttype(n) <= 0 (or maybe to consttype(n) == 0).

[mvdan]

Sounds good. I assume that would let us get rid of either or both of the n.Type == nil checks. Do you want to do the CL, or should I?

I wonder what we should do with this issue, though. Perhaps we could rewrite it to "check that none of the Val.Interface() calls can possibly panic", as that is definitely desirable as far as I can see.

[mdempsky]

Go ahead and prepare a CL if you're interested.

I think you can just put "Fixes #22001." in it. I think once we cleanup consttype that the underlying concern here has been reasonably addressed.

[mvdan]

Fair enough - thanks for your help :)

[gopherbot]

Change https://golang.org/cl/69510 mentions this issue: cmd/compile: make bad Ctypes be only 0