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

cmd/compile: confusing error messages when a type is repeated #8853

Open
btracey opened this issue Oct 2, 2014 · 8 comments
Open

cmd/compile: confusing error messages when a type is repeated #8853

btracey opened this issue Oct 2, 2014 · 8 comments
Labels
Suggested Issues that may be good for new contributors looking for work to do.
Milestone

Comments

@btracey
Copy link
Contributor

btracey commented Oct 2, 2014

Code:
http://play.golang.org/p/MoahP8X1aD

If a type is defined twice in a given package, this can lead to unfortunate interface
assignment errors. As an example, in the code above, "type Foo int" exists
twice. The error message is

prog.go:9: Foo redeclared in this block
    previous declaration at prog.go:3
prog.go:18: cannot convert Bar literal (type Bar) to type Fooer:
    Bar does not implement Fooer (wrong type for Foo method)
        have Foo() Foo
        want Foo() Foo

In this particular case it's fine because the "Foo redeclared" error comes
first, but in my actual code the interface conversion error was returned first and then
there were more errors before the redeclaration error.
@ianlancetaylor
Copy link
Contributor

Comment 1:

Labels changed: added repo-main, release-none, suggested.

Status changed to Accepted.

@btracey btracey added accepted Suggested Issues that may be good for new contributors looking for work to do. labels Oct 2, 2014
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@rsc rsc changed the title cmd/gc: confusing error messages when a type is repeated cmd/compile: confusing error messages when a type is repeated Jun 8, 2015
@agnivade
Copy link
Contributor

@btracey - Can you post the code where you got the interface conversion error before the redeclaration error ? And possibly those "more errors".

In my testing, the errors come linearly in the order in which they are written in the source code. If I redeclare before trying to convert the interface, it gives me the redeclaration error before. Vice-versa, it gives the interface conversion error before. This seems like reasonable behavior to me.

@agnivade agnivade added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jun 16, 2018
@gopherbot
Copy link

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@btracey
Copy link
Contributor Author

btracey commented Jul 16, 2018

Sorry, this bug report is from a long time ago and I don't have any memory of what the code would have been. I believe though that the problem was I had a many compile errors, and so I was only getting the error saying the interface type can't be converted, and the redeclared error. was not printed

@odeke-em odeke-em reopened this Jul 16, 2018
@btracey
Copy link
Contributor Author

btracey commented Jul 16, 2018

The issue is that the

        have Foo() Foo
        want Foo() Foo

Is very confusing. It would be better to not print, or print something else, if the strings are identical

@ianlancetaylor ianlancetaylor removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jul 16, 2018
@ianlancetaylor
Copy link
Contributor

@agnivade We should not be printing

    have Foo() Foo
    want Foo() Foo

That is not helpful at any level. We should suppress that error for duplicate types, given that the duplicate type is already going to cause an error.

@agnivade
Copy link
Contributor

Ah, thank you for the clarification. I thought the issue was about the order of the errors.

@smasher164
Copy link
Member

Is interface conversion the only place where this problem can appear? If so, would it be enough to return OCONVIFACE in assignop when the have and want strings match? This is considering the fact that the typechecker only reports the mentioned error when the returned Op == 0.

@odeke-em odeke-em self-assigned this Jun 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Suggested Issues that may be good for new contributors looking for work to do.
Projects
None yet
Development

No branches or pull requests

7 participants