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
internal/refactor/inline: insert conversions during substitution
Previously, we rejected arguments as substitution candidates
if their type (or its types.Default) did not exactly match
the parameter type. Now, we allow those substitutions to
proceed but we wrap the argument in an explicit conversion
so that the meaning of the program doesn't change.
We had initially been reluctant to do this out of concern
that it could cause a single conversion during argument
passing to be moved into a loop, where its dynamic cost
might be multiplied; for example, a string->any conversion
allocates memory. But we decided that this modest dynamic cost
is acceptable so long as the meaning does not change.
Also, this change includes a fix for golang/go#63193, in which the
type inferred for the argument expression in func(int16){}(1)
is not "untyped int" but "int16". In other words, the type
checker has incorporated knowledge of the parameter type.
It is unsafe to assume that the expression 1 will have the
same type in a different context, so we recompute the type
of each argument expression in a neutral context (using
CheckExpr).
Fixesgolang/go#63193
Change-Id: I0fd072cc7611d113af77193f6d3362268d9af158
Reviewed-on: https://go-review.googlesource.com/c/tools/+/530975
Reviewed-by: Robert Findley <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Auto-Submit: Alan Donovan <[email protected]>
0 commit comments