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: incorrect invalid field error in generic code #50148

Closed
randall77 opened this issue Dec 14, 2021 · 3 comments
Closed

cmd/compile: incorrect invalid field error in generic code #50148

randall77 opened this issue Dec 14, 2021 · 3 comments
Labels
generics okay-after-beta1
Milestone

Comments

@randall77
Copy link
Contributor

@randall77 randall77 commented Dec 14, 2021

a.go:

package a

type S[T any] struct {
}

func (b *S[T]) build() *X[T] {
	return &X[T]{f:0}
}
type X[T any] struct {
	f int
}

b.go:

package b

import "./a"

func B() {
	var x a.S[int]
	_ = x
}

main.go:

package main

import "./b"

func main() {
	b.B()
}

This should compile successfully. Instead we get the error:

a.go:7:16: invalid field name a.f in struct initializer

This is an error from the old typechecker when importing code (from b into main, I think). The error occurs in the phase where we're building more instantiations after inlining.

This example is reduced from an example generated by my generifier. It was originally package html_test importing package html importing a generified version of package string.

@danscales

@randall77 randall77 self-assigned this Dec 14, 2021
@randall77 randall77 added the generics label Dec 14, 2021
@randall77 randall77 added this to the Go1.18 milestone Dec 14, 2021
@randall77 randall77 added the okay-after-beta1 label Dec 14, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Dec 14, 2021

Change https://golang.org/cl/371554 mentions this issue: cmd/compile: allow field keys from different packages

@randall77
Copy link
Contributor Author

@randall77 randall77 commented Dec 14, 2021

This error occurs as part of typechecking a new generic instantiation, with the generic definition being in a separate package. It's unhappy about typechecking a unexported field reference in a package other than the one being compiled.
A similar error does not occur in 1.17, because during inlining we don't ever typecheck imported code - we just deserialize the types that were serialized on export.
A similar error does not occur in 1.16, because the type checker is happy to typecheck unexported field references in other packages. The error case was added here (as part of 1.17 development): https://go-review.googlesource.com/c/go/+/277713 @mdempsky

So I think we're ok allowing the typechecker to pass in this situation, as it used to 1.16 and earlier.
I do want to understand more about why we're calling the typechecker here. I don't think it should be necessary, which would probably be a better fix if it works out.

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Dec 14, 2021

Removing the types.LocalPkg check seems reasonable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
generics okay-after-beta1
Projects
None yet
Development

No branches or pull requests

3 participants