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

Comments

Projects
None yet
4 participants
@btracey
Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

btracey commented Sep 4, 2014

Comment 4:

Yes, exactly.

@btracey btracey added new labels Sep 4, 2014

@bradfitz bradfitz removed the new label Dec 18, 2014

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@rsc rsc changed the title from cmd/gc: In struct literals, type check outside in rather than inside out. to cmd/compile: In struct literals, type check outside in rather than inside out. Jun 8, 2015

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