cmd/compile: local type declarations in generic code don't work #47631
Comments
|
Change https://golang.org/cl/341213 mentions this issue: |
seankhliao
added
the
NeedsFix
|
@findleyr pointed out that local generic types in non-generic functions somewhat work now: Of course, if instead of main, we had an exported, inlinable function F, then we would get the same failure, since we would try to export F. But just wanted to mention this case, since we need to either support it or disable it, depending on whether we support local generic types in Go 1.18. |
|
FWIW some cases give a different kind of panic. For example https://go2goplay.golang.org/p/snfHm-qGhGD gives me this traceback: It works fine if the struct type is anonymous. |
|
Probably not that helpful, but FWIW, here is another example that fails on tip (640a49b Sat Oct 16 16:27:40 2021 +0000) with package p
func P[T any](T) {
type w []w
}
func A() { P([]string{}) } |
|
Change https://golang.org/cl/355351 mentions this issue: |
|
IMO this issue should be labeled as release-blocker, local type declarations are fairly common. |
|
For additional information (or test), here are a couple more examples where this issue is exposed: And bool64/cache#11 (https://github.com/bool64/cache/runs/4090471755?check_suite_focus=true#step:5:28) |
|
Change https://golang.org/cl/364054 mentions this issue: |
…unctions We hope to support this feature one day, but it doesn't work currently. Issue a nice error message instead of having the compiler crash. Update #47631 Change-Id: I0359411410acbaf9a5b9dbb988cd933de1bb8438 Reviewed-on: https://go-review.googlesource.com/c/go/+/364054 Trust: Keith Randall <khr@golang.org> Trust: Dan Scales <danscales@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
|
This feature is being pushed back to 1.19. |
|
Change https://golang.org/cl/364134 mentions this issue: |
Also mention local types restriction. We probably want to say more at some point, this is just a placeholder to start. Update #47631 Change-Id: I828e451e1e8504d21cb55c7132e9cb330b160a54 Reviewed-on: https://go-review.googlesource.com/c/go/+/364134 Trust: Keith Randall <khr@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
|
Change https://golang.org/cl/364314 mentions this issue: |
Updates #47631 Fixes #49611 Change-Id: Ib4a4466038e0d4a9aa9380d7909f29f7d15c6c69 Reviewed-on: https://go-review.googlesource.com/c/go/+/364314 Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
|
Change https://golang.org/cl/372154 mentions this issue: |
|
can we support type alias in generic code? package main
type S1[T any] struct {
}
func (s S1[T]) Build(fn func(t *T)) T {
var t T
fn(&t)
return t
}
type Container[T any] struct {
Value T
}
type S2[T any] struct{}
func (s S2[T]) Build() Container[T] {
type valueType = Container[T]
return S1[valueType]{}.Build(func(t *valueType) {
*t = valueType{}
})
}
func main() {
}this type alias could significantly improve code readability, typically in complicate code. |
The seed obfuscator uses a type declaration in order to declare a function, which returns a function with the same type. This breaks when obfuscating literals inside generic functions, because type declarations inside generic functions are not currently supported. Therefore the obfuscator gets disabled until golang/go#47631 is fixed.
The seed obfuscator uses a type declaration in order to declare a function, which returns a function with the same type. This breaks when obfuscating literals inside generic functions, because type declarations inside generic functions are not currently supported. Therefore the obfuscator gets disabled until golang/go#47631 is fixed.
|
Should this be moved to Go 1.20? This is a new feature and we're already in the freeze. CC @randall77 |
gopherbot
added
the
compiler/runtime
|
I'm told this is no longer a release blocker, so I'm dropping that label. I'll otherwise leave it as Todo and assigned to Keith. |
|
This is now fixed with unified IR. |
This looks like a general problem that we can't export/import local type declarations, including for inlining.
The text was updated successfully, but these errors were encountered: