Skip to content
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

Jump to bottom

go/types: "const _ string = 1" error message says integers can't be converted to strings #22070

Closed
mdempsky opened this issue Sep 27, 2017 · 9 comments
Closed

go/types: "const _ string = 1" error message says integers can't be converted to strings #22070

mdempsky opened this issue Sep 27, 2017 · 9 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unplanned

Comments

@mdempsky
Copy link
Member

Compiling this package with cmd/compile (or go/types) produces an error message that 1 cannot be "converted" to type string. In fact it can be converted, it just can't be assigned, which is the criteria required here by the language spec.

package p
const _ string = 1

/cc @griesemer
@go101
Copy link

go101 commented Sep 28, 2017 •
edited

The accurate message should be cannot implicitly convert 1 to type string.

There are many error messages are not very accurate. Another example:

type T *int
type S struct {
	T // error: embedded type cannot be a pointer
}

The accurate message should be embedded type cannot be a defined pointer

@mdempsky
Copy link
Member Author

I think the correct wording is cannot assign 1 to type string. The only time the spec talks about "implicit conversions" is in the context of default type for untyped constants, which does not apply here.

The embedded type error message reads fine to me as is. T is still a pointer type.

@go101
Copy link

go101 commented Sep 29, 2017

Yes, T is a pointer, that is why the message is not accurate.
In fact, embedded type can be a pointer.
It is just that embedded type cannot be a defined pointer.

type T *int
type S struct {
	T // error: embedded type cannot be a pointer
}
type S struct {
	*int // ok. 
}

@ianlancetaylor ianlancetaylor added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 29, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Mar 29, 2018
@griesemer
Copy link
Contributor

The error message is inaccurate, but we do get an error message. Not urgent.

@griesemer griesemer modified the milestones: Go1.11, Unplanned May 31, 2018
@griesemer griesemer self-assigned this May 31, 2018
@cuonglm
Copy link
Member

cuonglm commented Apr 6, 2020

With current tip, the error message:

$ go tool compile p.go
p.go:3:7: cannot use 1 (type untyped int) as type string

Should we close this @griesemer @mdempsky ?

@griesemer
Copy link
Contributor

griesemer commented Apr 6, 2020 •
edited

@cuonglm Thanks for noticing this. The compiler does the right think now. go/types still reports "cannot convert 1 (untyped int constant) to string". I will retitle the issue.

Still not urgent.

@griesemer griesemer changed the title cmd/compile: "const _ string = 1" error message says integers can't be converted to strings go/types: "const _ string = 1" error message says integers can't be converted to strings Apr 6, 2020
@gopherbot
Copy link

Change https://golang.org/cl/242083 mentions this issue: go/types: better error when converting untyped values in assignments

gopherbot pushed a commit that referenced this issue Aug 27, 2020
@findleyr
go/types: better error when converting untyped values in assignments
346efc2 
The error returned by convertUntyped is 'cannot convert _ to _', which
can be misleading in contexts where an explicit conversion would be
allowed.

Arguably the error message from convertUntyped should just be 'cannot
use _ as _', as 'convert' has an explicit meaning within the spec.
Making that change caused a large number of test failures, so for now we
just fix this for assignments by interpreting the error.

For #22070

Change-Id: I4eed6f39d1a991e8df7e035ec301d28a05150eb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/242083
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
@gopherbot
Copy link

Change https://golang.org/cl/267717 mentions this issue: go/types: simplify error messages for untyped value assignability

gopherbot pushed a commit that referenced this issue Nov 5, 2020
@findleyr
go/types: simplify error messages for untyped value assignability
0556831 
CL 242083 corrected an inaccurate error message related to the
assignability of untyped constant values. Previously the error message
was of the form "cannot convert ... to ...", which is misleading when
there is no explicit conversion in the syntax. The new error message
corrected this to "cannot use ... as ... in ...", but also appended an
inner error message that can be quite verbose. For example:

  cannot use "123" (untyped string constant) as int value in assignment:
  cannot convert "123" (untyped string constant) to int"

This might be more accurate, but is a regression in readability. Correct
this by only including the inner error message in the rare cases where
it is helpful: if the constant value overflows or is truncated.

For #22070

Change-Id: I8b8ee6ef713f64facc319894be09398b0b5ea500
Reviewed-on: https://go-review.googlesource.com/c/go/+/267717
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
@findleyr
Copy link
Contributor

The error message is now "cannot use 1 (untyped int constant) as string value in constant declaration", so I think this can be closed.

@golang golang locked and limited conversation to collaborators Apr 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
7 participants
@mdempsky @ianlancetaylor @cuonglm @griesemer @gopherbot @go101 @findleyr