/cc @randall77

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

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

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.

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).

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.

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.

Fair enough - thanks for your help :)

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