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: In struct literals, type check outside in rather than inside out. #8659

Open
btracey opened this issue Sep 4, 2014 · 4 comments
Open
Assignees
Milestone

Comments

@btracey
Copy link
Contributor

@btracey btracey commented Sep 4, 2014

When constructing a struct literal, the types appear to be checked from the "inside
out", that is, it appears that the last thing checked is that the variable type
matches the struct field. This leads to http://play.golang.org/p/vwvF9uNyhU, where the
error is really that the outer literal should be [][]float64, not that the inner
literals are the wrong type.
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 4, 2014

Comment 1:

The basic problem is a type mismatch.  I think you're suggesting that when there is a
type mismatch between the type of the composite literal and its elements that we should
report the error on the type rather than the elements.  But sometimes that will be wrong
too.  How can we know where it would be better to report an error?  It's not a
rhetorical question; if you can suggest a simple algorithm, perhaps we can implement it.

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

@btracey
Copy link
Contributor Author

@btracey btracey commented Sep 4, 2014

Comment 2:

> I think you're suggesting that when there is a type mismatch between the type of the
composite literal and its elements that we should report the error on the type rather
than the elements.
If I understand you correctly, that's not what I'm suggesting. I'm suggesting that we
check that the type of the field and the element match before checking that values
within the element are correct. In the example code:
type Foo struct{
    Elem [][]float64
}
func main(){
    _ = Foo{
          Elem: []float64{ // other code},
      }
}
this code is wrong no matter what "other code" contains, because Elem has type
[][]float64, but the value has type []float64. I'm suggesting that this be checked
before checking that the types within "// other code" are correct.
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 4, 2014

Comment 3:

Ah, I see, and I assume you are suggesting that in addition to that check, if the type
of the composite literal does not match the type of the field, we should suppress errors
about elements of the composite literal.
@btracey
Copy link
Contributor Author

@btracey btracey commented Sep 4, 2014

Comment 4:

Yes, exactly.
@bradfitz bradfitz removed the new label Dec 18, 2014
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@rsc rsc changed the title cmd/gc: In struct literals, type check outside in rather than inside out. cmd/compile: In struct literals, type check outside in rather than inside out. Jun 8, 2015
@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
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants