cmd/compile/internal/ir: OCONVNOP is documented as having no effect, but it might change the type

[mateusz834]

I am unsure whether this is a bug or not, but the current docs of OCONVNOP is as follows:

go/src/cmd/compile/internal/ir/node.go

Line 172 in 6e0a81a

OCONVNOP // Type(X) (type conversion, no effect)

Note the "no effect", but actually it can change the type:

type Impl struct{}
type implWrapper Impl

func _() {
	i := &Impl{}
        _ = (*implWrapper)(i) // OCONVNOP
}

Is this the expected behavior? If so i think that the docs should be updated, as it might be confusing (as it is a NOP).

CC @golang/compiler

[randall77]

The point of OCONVNOP is to change the type.
Like this:

type T int64

func f(x int64) T {
	return T(x)
}

The NOP means that no code is needed to do it.

Sure, we can update the docs to be more clear about it.

[mateusz834]

Thanks, my initial thought was only cases like: int(int(0)).

That makes me also think whether ir.StaticValue should check for such cases, currently it follows such CONVs:

go/src/cmd/compile/internal/ir/expr.go

Lines 857 to 864 in 3c05790

	func StaticValue(n Node) Node {
	for {
	switch n1 := n.(type) {
	case *ConvExpr:
	if n1.Op() == OCONVNOP {
	n = n1.X
	continue
	}

At least it does not seem to cause any issues for the devirtualizer, as there also is a OCONVINTER, which is not followed here.

[gabyhelp]

Related Issues

• cmd/compile: interface conversion using OCONVNOP incorrectly #18595 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}