New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: incorrect and duplicate error for invalid string conversion #21979

Open
griesemer opened this Issue Sep 22, 2017 · 12 comments

Comments

Projects
None yet
6 participants
@griesemer
Contributor

griesemer commented Sep 22, 2017

https://play.golang.org/p/nqGlIR42-9

produces:

tmp/sandbox179252628/main.go:4:12: cannot convert 1 to type string
tmp/sandbox179252628/main.go:4:12: cannot convert 1 (type float64) to type string

The first error is incorrect (1 can be converted to string, but not 1.0); it's also not necessary. The 2nd error would be sufficient.

@griesemer griesemer added this to the Go1.10 milestone Sep 22, 2017

@gopherbot

This comment has been minimized.

gopherbot commented Sep 22, 2017

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

@frikkasoft

This comment has been minimized.

frikkasoft commented Sep 22, 2017

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

@griesemer

This comment has been minimized.

Contributor

griesemer commented Sep 22, 2017

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.

@kshvmdn

This comment has been minimized.

Contributor

kshvmdn commented Sep 22, 2017

Duplicate of #20812? Does this reproduce on tip?

@frikkasoft

This comment has been minimized.

frikkasoft commented Sep 22, 2017

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

@odeke-em

This comment has been minimized.

Member

odeke-em commented Sep 23, 2017

I can conform that @kshvmdn's CL https://go-review.googlesource.com/46912 fixed the double error printing issue
screen shot 2017-09-22 at 6 49 56 pm

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

@kshvmdn

This comment has been minimized.

Contributor

kshvmdn commented Sep 23, 2017

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.

@odeke-em

This comment has been minimized.

Member

odeke-em commented Sep 23, 2017

@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

// sigrepr is a type's representation to the outside world,
// in string representations of return signatures
// e.g in error messages about wrong arguments to return.
func sigrepr(t *types.Type) string {
switch t {
default:
return t.String()
case types.Types[TIDEAL]:
// "untyped number" is not commonly used
// outside of the compiler, so let's use "number".
return "number"
case types.Idealstring:
return "string"
case types.Idealbool:
return "bool"
}
}

@kshvmdn

This comment has been minimized.

Contributor

kshvmdn commented Sep 23, 2017

@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?

@odeke-em

This comment has been minimized.

Member

odeke-em commented Sep 23, 2017

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

gopherbot pushed a commit that referenced this issue Sep 25, 2017

go/types: don't accept incorrect shift expression arguments
Under certain circumstances involving shifts, go/types didn't verify
that untyped constant values were representable by the relevant type,
leading to the acceptance of incorrect programs (see the issue).

Fixing this code exposed another problem with int-to-string conversions
which suddenly failed because now the type-checker complained that a
(constant) integer argument wasn't representable as a string. Fixed that
as well.

Added many additional tests covering the various scenarious.

Found two cmd/compile bugs in the process (#21979, #21981) and filed
a go/types TODO (#21982).

Fixes #21727.

Change-Id: If443ee0230979cd7d45d2fc669e623648caa70da
Reviewed-on: https://go-review.googlesource.com/65370
Reviewed-by: Alan Donovan <adonovan@google.com>
@griesemer

This comment has been minimized.

Contributor

griesemer commented Sep 25, 2017

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.

@mdempsky mdempsky modified the milestones: Go1.10, Go1.11 Nov 29, 2017

@griesemer

This comment has been minimized.

Contributor

griesemer commented May 31, 2018

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

@griesemer griesemer modified the milestones: Go1.11, Unplanned May 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment