go/types: inconsistent handling of untyped expressions

[mdempsky]

Currently if you type check this code with go/types:

var (
    _ int = 0
    _ = int(0)
    _ *int = nil
    _ = (*int)(nil)
)

both 0 expressions will have type "int", whereas the first nil expression will have type "untyped nil", and the second will have type "*int". This seems at the least inconsistent. See http://play.golang.org/p/cw8Ldz1U5D

My expectation was that the 0s would type check as "untyped int" and the nils would type check as "untyped nil". The current behavior of rewriting the type of untyped expressions seems to have two negative consequences that I've noticed trying to use go/types:

1. It makes it difficult to identify useless conversion operations; i.e., expressions T(x) where x is already of type T. Expressions like int(0) will trigger as false positives.
2. It causes types.TypeAndValue.IsNil to return false for the nil subexpression in (*int)(nil), because it doesn't have the type "untyped nil" anymore.

It also seems inconsistent with conversions of already typed expressions, where they're not rewritten.

However, I notice api_test.go has a bunch of tests that seem to explicitly test for this behavior, so it seems intentional?

CC @griesemer

[griesemer]

@mdempsky It is definitively intentional - untyped constants are given their "inferred" type so that a backend - which needs to materialize the constants - knows of what type and size a constant is.

My guess would have been - for the example above - that the types would be int, untyped int, *nil, and untyped nil, but I need to look into the logic again.

I suspect the reason for the inconsistency is that nil is not considered a constant and thus perhaps is handled in a different code path.

[mdempsky]

I'd think the backend could determine the needed type and size for materializing the constants some other way (e.g., looking at the type of the variable they're being assigned to)? But at least if 0 in int(0) and nil in (*int)(nil) became "untyped int" and "untyped nil", respectively, like you suggest, that would help my immediate problem of wanting to identify unnecessary conversions.

[mdempsky]

I took a stab at this, but discovered the trivial fix (just don't propagate types to explicit conversion arguments) causes a regression on this test case in test/fixedbugs/bug193.go, because it no longer detects the expected errors:

func main() {
        s := uint(10)
        ss := 1 << s
        y1 := float64(ss)
        y2 := float64(1 << s) // ERROR "shift"
        y3 := string(1 << s)  // ERROR "shift"
        _, _, _, _, _ = s, ss, y1, y2, y3
}

I'm actually rather surprised to find out the above is not valid Go (whereas float64(1 << uint(10)) is valid), but it seems to be in the spec:

If the left operand of a non-constant shift expression is an untyped constant, it is first converted to the type it would assume if the shift expression were replaced by its left operand alone.

Hrm.

[griesemer]

@mdempsky yes, shifts are tricky business . i'll take care of this (let me know if this is blocking you)

[mdempsky]

Nope, not blocking me. I was just interested in better understanding the problem.

[griesemer]

Investigate and decide what to do.

[bradfitz]

Ping Robert. You'd labeled this Go 1.9.

[mdempsky]

I think this can be safely bumped to 1.10. Nothing changed during 1.9 with respect to this issue.