You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ssa package defines an opaqueType, which is an "opaque and degenerate" type, currently used by the Range instruction. It truly is degenerate, embedding a nil types.Type, causing a call to types.Type.Underlying to panic.
Code that wants to operate on the types of instructions needs to specifically check for the Range instruction and skip it. There doesn't seem to be a way to check for this degenerate type specifically, which would at least permit passing types around without having to keep track of the originating instruction.
The simplest solution that I can think of is to implement Underlying as the identity function. However I suspect that this hasn't been done for a good reason?
New tasks include:
golang/go#19675 cmd/vet: report uses of -0 in float32/64 context
golang/go#19683 cmd/compile: eliminate usages of global lineno
golang/go#19670 x/tools/go/ssa: make opaqueType less annoying to use
golang/go#19636 encoding/base64: decoding is slow
golang/go#23471 x/perf/cmd/benchstat: tips or quickstart for newcomers
golang/go#19577 test: errorcheck support for intraline errors
golang/go#19490 cmd/vet: reduce the amount of false positives for -shadow mode
golang/go#19042 cmd/internal/obj: optimize wrapper method prologue for branch prediction
golang/go#19013 cmd/compile: add tool for understanding/debugging SSA rules
gopherbot
added
the
Tools
This label describes issues relating to any tools in the x/tools repository.
label
Sep 12, 2019
The simplest solution that I can think of is to implement Underlying as the identity function. However I suspect that this hasn't been done for a good reason?
The reason I used this annoying type was to help point out (by making the program explode) places where a client assumes that ssa.Range has a legal Go type. In hindsight it would have been better to use an inaccurate but valid type such as (), instead of creating a minefield.
The ssa package defines an opaqueType, which is an "opaque and degenerate" type, currently used by the Range instruction. It truly is degenerate, embedding a nil types.Type, causing a call to types.Type.Underlying to panic.
Code that wants to operate on the types of instructions needs to specifically check for the Range instruction and skip it. There doesn't seem to be a way to check for this degenerate type specifically, which would at least permit passing types around without having to keep track of the originating instruction.
The simplest solution that I can think of is to implement Underlying as the identity function. However I suspect that this hasn't been done for a good reason?
/cc @alandonovan
The text was updated successfully, but these errors were encountered: