x/tools/internal/refactor/inline: some implicit conversions are undetectable using go/types

[adonovan]

Consider func f(x int16) { y := x; _ = (*int16)(&y) }. If inlining a call f(1) results in parameter substitution then the output is something like { y := 1; _ = (*int16)(&y) }, which doesn't compile because the type of y has changed from int16 to int.

The inliner already has a check in place so that nontrivial implicit conversions prevent substitution, but the check does not fire in this case because, according to the type checker, the type of the constant 1 in f(1) is int16, not untyped int. (I'm pretty sure I requested this helpful feature years ago, sigh.) Once the program has been transformed, the statement y := 1 has forgotten all about int16.

Unfortunately I think we will need an additional analysis of the argument expression to ascertain whether its type is a purely "bottom-up" property of the syntax or depends on a "top-down" property of the context. If CheckExpr were less inflexible we might be able to invoke it on the argument expression (effectively, with no context) to see what type it gives.

@griesemer @findleyr

[findleyr]

Yes, this is an unfortunate loss of information (in retrospect, a nice goal for go/types would be to lose no information, but it took me a long time to realize that).

Supposing we wanted to fix this, I can think of two approaches:

1. Add another map to types.Info.
2. Add a new CheckExpr-like API that works the way we want.

I feel like I'd rather invest in (2), though I can't say for certain that it is feasible. What do others think?

[adonovan]

If #62664 (comment) we might be able to invoke it on the argument expression (effectively, with no context) to see what type it gives.

I was unnecessarily critical of CheckExpr. It solves this problem neatly.

[timothy-king]

My worry about CheckExpr with no context is more complex expressions with constants:

func f(x int16) { y := x; _ = (*int16)(&y) }
const c = 1
f(c+2) // inline

[gopherbot]

Change https://go.dev/cl/530975 mentions this issue: internal/refactor/inline: insert conversions during substitition

[adonovan]

My worry about CheckExpr with no context is more complex expressions with constants:
func f(x int16) { y := x; _ = (*int16)(&y) }
const c = 1
f(c+2) // inline

With my pending CL 530975, this example inlines to:

            	const c = 1
            	{
            		y := int16(c + 2)
            		_ = (*int16)(&y)
            	}

which is correct.