Change https://golang.org/cl/65370 mentions this issue: go/types: don't accept incorrect shift expression arguments

I am interested in contributing to Go - is this a good issue for a first-time contributor?

Yes and no. Yes because I suspect the actual fix might be small (a missing check somewhere); no because it requires digging into the compiler internals which can be daunting.

That said, why don't you give it a shot and see how far you get. Send any CLs to me (gri) or mdempsky, please. Thanks.

Duplicate of #20812? Does this reproduce on tip?

Thanks, I will take a look at this over the weekend/early next week.

I can conform that @kshvmdn's CL https://go-review.googlesource.com/46912 fixed the double error printing issue

However, there is a change in error message, it now says 1 (type untyped number) instead of 1 or 1 (type float64).

Thanks for the confirmation, @odeke-em!

Unfortunately, as discussed in the CL, I couldn't seem to find a way of adding more relevant type information to the first error message. Maybe @frikkasoft, @griesemer, or someone else will be able to find a better solution.

@kshvmdn thanks for the CL and fix btw. So in regards to relevant information to that type, perhaps this helper that I added in https://go-review.googlesource.com/c/25156/ could help out with that message

@odeke-em, cool, I wasn't aware of this function!

So this change:

--- a/src/cmd/compile/internal/gc/const.go
+++ b/src/cmd/compile/internal/gc/const.go
@@ -408,7 +408,7 @@ func convlit1(n *Node, t *types.Type, explicit bool, reuse canReuseNode) *Node {
 bad:
        if !n.Diag() {
                if !t.Broke() {
-                       yyerror("cannot convert %L to type %v", n, t)
+                       yyerror("cannot convert %v (type %v) to type %v", n, sigrepr(n.Typ()), t)
                }
                n.SetDiag(true)
        }

results in the message saying 1 (type number) instead of 1 (type untyped number). Is this preferred or would it be better to include the untyped information?

Thanks for trying it out @kshvmdn, in this case, I'll defer to @mdempsky and @griesemer but IMHO I'd fly with type number rather than type untyped number

My apologies for not checking at tip myself before filing this. That said, the error is still misleading: string(1) is valid; string(1.0) is not. Ideally the fact that the argument is a floating-point constant shows up in the error message.

Inaccurate error message, but we do get an error message. Not urgent.

Change https://golang.org/cl/191079 mentions this issue: cmd/compile: improve error for invalid string conversion

Reopening this, because I reverted it with CL 193977 (e6ba19f).

To summarize the current standing of the issue, given

const _ = string(1.0)

we currently report:

cannot convert 1 (untyped number) to string

Like @griesemer pointed out, this is a vague and somewhat misleading error message: it's okay to convert untyped integers to string, but not untyped floats. Unfortunately, the error message doesn't disambiguate the two.

CL 191079 attempted to fix this by changing it to report:

cannot convert 1 (float64) to string

However, this is technically incorrect: 1's type is not float64, but "untyped float constant". (Admittedly though, the difference is probably irrelevant to many Go programmers.)

go/types correctly reports "untyped float constant", and cmd/compile should do the same.

Change https://golang.org/cl/194019 mentions this issue: cmd/compile: report more precise errors about untyped constants