profile
viewpoint

griesemer/tryhard 103

tryhard finds and rewrites code suitable for try.

rhu1/fgg 68

Mini prototype of FG/FGG/FGR in Go.

griesemer/dotGo2016 21

Prototype implementation of operator methods (fork of https://github.com/golang/go)

griesemer/2016-talks 10

Slides and Links to slides for 2016 talks

griesemer/proposal 5

Go Project Design Documents

griesemer/ivy 4

ivy, an APL-like calculator

issue closedgolang/go

go/types: "duplicate case in expression switch" error could be formatted better (perhaps)

$ go version
go version devel +3df1f00bfc Thu Jul 12 08:22:37 2018 +0000 linux/amd64
$ cd src/go/types
$ go build gotype.go
$ cat f.go
package p

func f(r rune) {
        switch r {
        case 'a':
        case 'a':
        }
}
$ ./gotype f.go
f.go:6:7: duplicate case 'a' (constant 97 of type rune) in expression switch
f.go:5:7:       previous case

Haven't digged into why this error appears to be broken.

/cc @griesemer

closed time in a day

mvdan

issue commentgolang/go

go/types: "duplicate case in expression switch" error could be formatted better (perhaps)

I think this ok as is. The 2nd line is really just clarifying the error, it's not another error. Closing as working as intended.

mvdan

comment created time in a day

issue commentgolang/go

proposal: Go 2: generics: use operators for meta typing

@markusheukelom This is a great question. We absolutely need to develop good conventions and "best practices" around the use of generics.

I'll try to answer for your specific example: I believe in this case ReadAll1 (no generics) is the correct choice because of the following reasons:

  • There is no improvement in static type safety at the call site with the generic version: The results are fixed (don't depend on the argument type), both for the ReadAllX functions and the Read method. The provided reader may be nil in the ReadAll1 case which might lead to a panic inside that function, but note that ReadAll2 could be instantiated with a pointer or interface type, too, and then have the same problem.

  • There is (likely) no improvement in memory layout/use with the generic version: There is a single reader to pass, and while it may need to be packed into an interface, that cost is minimal.

  • There is (likely) no improvement in performance with the generic version: This makes some assumptions about the cost of a Read, but its likely that the cost of performing the Read dwarfs the cost of making the Read method call via the interface compared to having a (possibly) direct call of Read in the generic version.

On the other hand, there is a cost of having a generic version for each type of Reader, depending on how the compiler translates this code.

(Note, this specific situation may be a case where a compiler might choose to implement the generic version like the non-generic version.)

In summary, if the generic version doesn't improve the code along the axes of static type safety, memory use, and performance, choose the non-generic version.

Here's another way of looking at this: Generics are essentially a "glorified" version of macros. Would you use a macro in this case (because it might give you a significant benefit)? I think the answer would be a clear "no".

markusheukelom

comment created time in 2 days

issue closedgolang/go

cmd/go2go: orderedmap.NewOrdered returns -1 for less than and greater than cases

Hi folks,

I was talking a look at the nice code examples for generics in Go 2 path and found a small big in one of them.

What version of Go are you using (go version)? Go 2 What operating system and processor architecture are you using? N/A What did you do? Read the code at /src/cmd/go2go/testdata/go2path/src/ What did you expect to see? Correct examples on how to use generics. What did you see instead? One bug in orderedmap.NewOrdered.

https://github.com/golang/go/blob/e9e897e0feea35b7e623d91587241bf33af2294c/src/cmd/go2go/testdata/go2path/src/orderedmap/orderedmap.go2#L42-L49

This probably shouldn't be negative 1: https://github.com/golang/go/blob/e9e897e0feea35b7e623d91587241bf33af2294c/src/cmd/go2go/testdata/go2path/src/orderedmap/orderedmap.go2#L48

closed time in 3 days

rcdmk

issue commentgolang/go

cmd/go2go: orderedmap.NewOrdered returns -1 for less than and greater than cases

Fixed in dev.go2go repo. Thanks for reporting.

rcdmk

comment created time in 3 days

issue commentgolang/go

cmd/go2go: type parameter order is significant when it should not be

Thanks for this. Another case where the prototype type-checks too eagerly. This is a problem we need to solve in general in a real implementation (probably requires a two-phase approach). Addressing this should resolve a large number of bugs (not just with generics but elsewhere as well).

rogpeppe

comment created time in 3 days

issue commentgolang/go

proposal: Go 2: generics: use operators for meta typing

PS: Worse, what if the generic function requires + (or Add) in the signature, the function internally does x + 1 (works with any numeric type) and then the type argument is string?

markusheukelom

comment created time in 3 days

issue commentgolang/go

proposal: Go 2: generics: use operators for meta typing

The issue is not about + vs Add, the problem is related to the use of constants in the generic code. If the API says the argument type needs to provide + (or Add, same thing), and the type byte is provided, the API is satisfied. Yet, if inside the generic function I add the value 1024 to a value of that generic type (in this case byte) what should happen? In regular Go, I cannot write x + 1024 if x is of byte type because 1024 overflows byte's range. That is, if we want to preserve regular Go behavior for generic functions, we need to express somehow in the API that the argument type not only supports +, but also that it must be "big enough" to handle the constant 1024. Otherwise we cannot type-check the function independent of the invocation because we don't have any information about the type parameter besides that it supports +.

Regarding the * vs + problem: If I write a generic function

func double[T *](x T) T { return 2*x }

and later decide that x+x runs faster on my machine than 2*x, then I will need to change the function signature:

func double[T +](x T) T { return x+x }

even though the effect of the function didn't change. Sometimes such changes come about from refactoring. We don't want to need the API to change in such cases (and possibly break client code).

The current generics design draft doesn't have any of these problems because no operators are specified, only types (in an interface's type list). Given

func double[T interface{type int}] { return 2*x }

one can use any operation defined on an int type inside the double function. I can also use any constant that is accepted by an int type. Etc.

markusheukelom

comment created time in 3 days

issue commentgolang/go

proposal: Go 2: generics: use operators for meta typing

@changkun You mean "operator methods". But operator methods have the problem discussed here.

markusheukelom

comment created time in 3 days

issue commentgolang/go

cmd/compile: "invalid recursive type" error is not as helpful as go/types

We are seriously investigating using a revamped/adjusted go/types for the compiler in the future. The result should be consistent and better error messages from both, the compiler and the type checker.

mvdan

comment created time in 3 days

issue commentgolang/go

cmd/go2go: orderedmap.NewOrdered returns -1 for less than and greater than cases

Thanks. Yes, that looks like a typo.

rcdmk

comment created time in 3 days

issue commentgolang/go

proposal: Go 2: generics: use operators for meta typing

Regarding your reply: Yes, I indeed meant

func Inc[T +](a T) T {
	return a + 1234
}

Basically, what you are saying is that one cannot type-check this function independently from a call site (which may not yet exist if this is a library function). It's not just bytes. What if the constant is 1000000? What if it is negative and we have uint types? Etc.

Also, changing an implementation such that it uses + rather than * (or - rather than +!) is not unusual and shouldn't require an API change. It also shouldn't require the author to anticipate such a change and require all "possibly needed operators" to be listed in the API.

These are some of the reasons why the current generics design draft doesn't try to use operator methods in its constraints. It seems that your proposal has all the problems of operator methods.

markusheukelom

comment created time in 3 days

issue commentgolang/go

proposal: Go 2: generics: use operators for meta typing

Using your proposal, how would you express a generic function that increments a generic numeric integer argument by a given constant value, say 1234, and then returns that incremented value? Specifically, how would you express that you can't provide a byte argument because 1234 overflows byte? This is one of the problems one will need to address when constraining generic functions with operators, at least for Go.

Along similar lines, if one writes a generic function that uses * (multiplication) and down the road it turns out that the implementation can be made more efficient via a clever use of + (addition), would it be possible to change the implementation even if one had not foreseen the use of +; or would it require an API change?

markusheukelom

comment created time in 3 days

issue closedgolang/go

cmd/go2go: format in playground creates invalid code

The Format button in https://go2goplay.golang.org/ adds a type prefix to all the type parameters, which it then rejects as a syntax error. To reproduce, just go to https://go2goplay.golang.org/ and click Format, then Run.

closed time in 3 days

rogpeppe

issue commentgolang/go

cmd/go2go: format in playground creates invalid code

This is now also fixed in the playground after a recent update.

rogpeppe

comment created time in 3 days

issue commentgolang/go

proposal: Go 2 review meeting minutes

2020-09-15 / @griesemer, @iant

  • #41129 Go 2: Multi-dimensional slices
    • likely decline, final call for comments
  • #41148 Go 2: multiple value/tuple channels
    • likely decline, final call for comments
  • #41289 Go 2: add native type for map that maintains key order
    • likely decline, final call for comments
  • #39799 Go 2: interface methods
    • closed (no change in consensus)
  • #40353 Go 2: multivalue switch
    • closed (no further comments)
  • #40387 Go 2: accept multiple return values as the last arguments to function calls
    • closed (no further comments)
  • #40462 Go 2: allow fallthrough in type switches
    • closed (no further comments)
  • #40583 Go 2: use keywords throw, catch, and guard to handle errors
    • closed (no further comments)
griesemer

comment created time in 11 days

issue commentgolang/go

proposal: spec: type inferred composite literals

@ololosha228 What @neild said. Every language change, however small adds significant cost (compiler, tools, documentation, updating libraries if desired, eduction, etc.). We don't want to take on new things while we're trying to make progress on the generics front.

neild

comment created time in 11 days

issue commentgolang/go

cmd/go2go: improve error messages when types don't satisfy constraints

@urandom Well, a type list is a type constraint. But agreed, this should probably say "type list" instead (or whatever we use as the official terminology once we have a spec). Not urgent.

urandom

comment created time in 16 days

issue commentgolang/go

cmd/go2go: embedded types ignored in interface implementation

See https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#embedded-type-parameter-methods.

We know about this bug, but it's not urgent. Note that dev.go2go is a prototype. Not everything will be supported.

JavierZunzunegui

comment created time in 18 days

issue commentgolang/go

cmd/go2go: constraint type inference example from proposal causes panic

This should now be fixed in go/types. Final fix will need some adjustments in the go/go2go package.

rogpeppe

comment created time in 19 days

issue commentgolang/go

proposal: spec: generic programming facilities

The latest generics draft design is here. See also this comment re: discussions on this topic. Thanks.

adg

comment created time in 19 days

issue commentgolang/go

cmd/go2go: constraint type inference example from proposal causes panic

@ianlancetaylor 1) Constraint type inference did indeed not record the inferred signature if inference was applied to a partially provided (rather than inferred, from the value arguments) type parameter list. 2) Because sometimes we don't have an ast.CallExpr node, e.g. in this example FromStrings2[X] which is now an ast.IndexExpr node (but used to be an ast.CallExpr node in the past when we wrote FromStrings2(X)), we need to update which key is recorded in the Inferred map (best approach TBD).

In short, this is a bug in go/types, caused by the recent change of syntax. Once fixed in go/types, it may require some minimal adjustments in go/go2go.

rogpeppe

comment created time in 20 days

issue commentgolang/go

cmd/go2go: constraint type inference example from proposal causes panic

@ianlancetaylor I have a suspicion (to be confirmed): In the example, the expression FromStrings2[X] looks like an index expression - the parser cannot know that we have a function instantiation. When the type checker figures it out, it creates a new ast.CallExpr node on the fly (so we can re-use existing machinery). If that is the node that is recorded, there is no way to find it later...

Also, in go/go2go/rewrite.go, in the method translator.instantiationTypes(line 1042), for this example, the switch statement appears to see an ast.IndexExpr and thus does not look up t.importer.info.Inferred[x].

Need to investigate some more.

rogpeppe

comment created time in 20 days

issue commentgolang/go

cmd/go2go: constraint type inference example from proposal causes panic

@ianlancetaylor Judging from the code (go/types/call.go:400) inferred types should be recorded no matter the inference mechanism. Added some go/types tests (CL 253258) to confirm this.

rogpeppe

comment created time in 20 days

issue commentgolang/go

cmd/go2go: unexpected successful compilation

As @rsc pointed out, it is perfectly fine to write constraints that cannot be satisfied. (As an aside, your example can be satisfied: https://go2goplay.golang.org/p/VO-7h04CiAd .) This is not an issue with the prototype; it is permitted by the design draft.

Your 2nd example's constraint can also be satisfied: https://go2goplay.golang.org/p/nkhNZ1cBx-f.

Even in non-generic Go it is possible to write nonsensical code.

komkom

comment created time in 23 days

issue closedgolang/go

cmd/go2go: unexpected successful compilation

What version of Go are you using (go version)?

https://go2goplay.golang.org/

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

google chrome

What did you do?

I wrote the following https://go2goplay.golang.org/p/30SD7t_sLOa

What did you expect to see?

To see a compilation error. Or is this expected to compile and go vet will warn about it?

What did you see instead?

Successful compilation

closed time in 23 days

komkom

issue commentgolang/go

cmd/go2go: cannot infer generic interface types

@dmitshur ACK. Thanks for the reminder.

rogpeppe

comment created time in 23 days

issue commentgolang/go

cmd/go2go: format in playground creates invalid code

I assumed this was fixed with https://go-review.googlesource.com/c/go/+/251278 but I guess not. Trying once more.

The real fix is to remove all the various parsing and printing modes again, now that we have presumably settled on the type parameter list syntax.

rogpeppe

comment created time in 24 days

issue commentgolang/go

cmd/go2go: cannot infer generic interface types

Marked as FeatureRequest as this is not a bug in the prototype.

rogpeppe

comment created time in 24 days

issue commentgolang/go

proposal: Go 2 review meeting minutes

2020-09-01 / @bradfitz, @griesemer, @iant

  • #40821 Go 2: the "watch" statement for easier error handling & more
    • likely decline, final call for comments
  • #41129 Go 2: Multi-dimensional slices
    • gri commented
griesemer

comment created time in 25 days

issue commentgolang/go

proposal: Go 2: Multi-dimensional slices

For the sake of discussion, let's assume Go had support for multi-dimensional slices. Such slices would need to support a certain set of operations, such as creation/allocation of those slides, the ability to index elements, possibly iteration over the elements, maybe element-wise operations (adding two matrices), etc.

Also for the sake of discussion, I am going to make a few claims:

  1. Multi-dimensional slices are nice for small problems but don't scale. Real problems require detailed control over the layout of matrices: There is a reason why numerical libraries such as LINPACK, LAPACK, etc. but also gonum support various representations of matrices. There are dense and sparse matrices. There may be distributed matrices. The representations of these matrices can be very different from a basic multi-dimensional slice - at best they may use multi-dimensional slices underneath.

  2. AI applications, while operating on matrices, depend on maximum throughput and (typically) specialized hardware. To achieve the throughput or drive the hardware, the data must be brought into a suitable form which may be different from the "built-in" representation of matrices/multi-dimensional slices of a programming language. Again, real applications require detailed control over the layout of such data structures.

In summary, what we need is full programability of (memory) layout. And with programmability of layout we also need programmability of operations, as they depend on the layout.

  1. Go already provides support for that: it's called user-defined data types. With generics, we can also parameterize these data types (vectors, dense and sparse matrices, etc.) by element type. Using methods, we also can implement the necessary operations.

So if anything is missing it's perhaps convenience of notation, i.e., syntax.

  1. Operator methods are not sufficient. Simply permitting operator "names" such as +, *, etc. as method names (as in func (x *Vector) + (y *Vector) *Vector, so that we can write x + y which would mean x.+(y)) is a fairly easy language change but unfortunately it also doesn't scale. First, we don't just need operator methods, we probably also want operator method overloading: given a matrix m and a scalar value x, m + m would invoke the + method with a matrix receiver and argument, while m + x would have to invoke a method with a matrix receiver and a scalar argument. That is, we need two + methods (same name, different signatures), or perhaps a generic + method with method-specific type parameters. Operator overloading is not something we would be willing to add to Go (it would cause serious damage to the simplicity of method lookups); and generic methods are not sufficiently understood to be considered (see the generics draft design). One could make the 2nd operator parameter an empty interface and use a type switch inside the operator method, but that seems also not very satisfactory.

  2. But it gets worse: for performance, we would not write (for example) a matrix multiplication as B = A*x (translated to B = A.*(x)) because it would require a (possibly large) allocation for the result B. For performance, we would want to pass in the result memory as an argument (perhaps the receiver) to the operations. That is what math/big and the gonum package do. In short, unless there's yet another mechanism to somehow control how results are allocated, operator methods fall flat in real applications.

To make progress here we need to have strong arguments as to why these claims are wrong.

There's one thing we could do on the syntax side: we could perhaps support indexing methods. If we declare methods such as [] and []=

type Matrix[T Numeric] struct ...
func (m *Matrix[T]) [] (i, j int) T ... // getter: x = m[i, j] translates to x = m.[](i, j)
func (m *Matrix[T]) []= (i, j int, x T) ... // setter: m[i, j] = x translates to m.[]=(i, j, x)

we could implement multi-dimensional data structures in libraries yet provide notationally convenient access to the elements. Such methods would only accept a prescribed signature (n integer arguments and a result or argument of a given element type). (See also https://www.dotconferences.com/2016/10/robert-griesemer-prototype-your-design.)

RaananHadar

comment created time in 25 days

issue commentgolang/go

cmd/go2go: anonymous func with generics

Yes, that's one way to solve this. Btw., here's the updated example code: https://go2goplay.golang.org/p/mUWfsZPHs5h (now working with the latest type parameter syntax).

mattn

comment created time in 25 days

issue closedgolang/go

cmd/go2go: usage of interface with type list not as type constraint shouldn't be allowed

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version devel +ea8318cad7 Sat Aug 29 01:02:37 2020 +0000 windows/amd64 </pre>

Does this issue reproduce with the latest release?

n/a

What operating system and processor architecture are you using (go env)?

  • go2go playground
  • windows/amd64

What did you do?

https://go2goplay.golang.org/p/fD4PjTJLgdz <!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

What did you expect to see?

Successful compilation or better error message.

What did you see instead?

# play
./prog.go2:8: undefined: Nat

closed time in a month

tdakkota

issue commentgolang/go

cmd/go2go: usage of interface with type list not as type constraint shouldn't be allowed

Fixed on dev.go2go branch.

tdakkota

comment created time in a month

issue commentgolang/go

cmd/go2go: type stops satisfying constraint

The new error message is now:

tmp.go2:245:9: *mapIt[string, int, reverse[string, ReverseIterator[string]]] does not satisfy Iterator[T]: wrong method signature
                found func (*mapIt[T, U, I]).Next() (U, bool)
                want  func (Iterator[T any]).Next() (string, bool)

This can be improved further (the T, U, I parameters should be substituted), but this is already better than what we had.

Leaving this issue open for now for future improvements.

@urandom, please simplify test cases when reporting an issue; it makes it significantly easier to figure out what's going on.

urandom

comment created time in a month

issue commentgolang/go

cmd/go2go: embedded types ignored in interface implementation

Test case updated to new syntax: https://go2goplay.golang.org/p/Ssd4Ws7F91G

JavierZunzunegui

comment created time in a month

issue commentgolang/go

cmd/go2go: cannot infer T in an embedded field.

This is a variation of the same problem that plagues #39758. It's not yet implemented and thus leads to odd errors.

YoshikiShibata

comment created time in a month

issue closedgolang/go

cmd/go2go: missing error for use of uninstantiated type argument

package p

type A[type T] int

func f[type P]()

func _() {
	_ = f[A]
}

passes type-checking without error. But it should not be possible to instantiate f[A] with an uninstantiated A.

Follow-up on #40038.

closed time in a month

griesemer

issue commentgolang/go

cmd/go2go: missing error for use of uninstantiated type argument

Fixed on dev.go2go branch.

griesemer

comment created time in a month

issue closedgolang/go

cmd/go2go: erroneous "inconsistent use of () or [] for type parameters"

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version devel +722af87f62 Fri Aug 14 05:30:01 2020 +0000 linux/amd64 </pre>

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/binarycat/.cache/go-build" GOENV="/home/binarycat/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/binarycat/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/binarycat/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/binarycat/goroot" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/binarycat/goroot/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build338557042=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. --> I have 2 files in a directory: a.go:

package a
type A[type T] T

a_test.go

package a
import "testing"
func TestA(_ testing.T) {}

What did you expect to see?

PASS
ok      github.com/lolbinarycat/go2go-bug       0.007s

What did you see instead?

type checking failed for a
a_test.go2:1:1: inconsistent use of () or [] for type parameters

I'm not sure if this will replicate (it seemed inconsistent to me), so I'm also linking the actual project (emacs autosaves and all) here. run the command withing the ll directory.

closed time in a month

lolbinarycat

issue commentgolang/go

cmd/go2go: erroneous "inconsistent use of () or [] for type parameters"

We have settled for a syntax of type parameters that matches the syntax of regular parameters except that we use [] rather than (). The current prototype (dev.go2go branch, the playground may be a few days behind) now uses

  • [] for type parameters;
  • the type keyword is not needed (and not permitted);
  • each type parameter needs a constraint, which may be the predeclared identifier any (== interface{});
  • parameterized constraints must be fully instantiated.

See the latest draft design for details. Note that any is only valid in constraint position (it cannot be used as a general replacement for interface{} for now).

Your package a will need to be written

package a
type A[T any] T

Also, with this new syntax, an empty type parameter list in a generic type declaration would mean a slice type declaration and thus is not possible. For symmetry, a generic function declaration cannot have an empty type parameter list either (e.g., func f[](x int) is not permitted). Analogously, an empty instantiation such as f[](42) is not permitted.

Since the prototype has switched to the new syntax I will close this issue. Thanks.

lolbinarycat

comment created time in a month

issue commentgolang/go

cmd/doc: extra comment marker (//) included in terminal output for go doc cmd/compile

The output for https://golang.org/cmd/compile/ looks ok. I am guessing something goes wrong in the ToText function in go/doc/comment.go. Have not investigated yet.

inrick

comment created time in a month

issue closedgolang/go

cmd/go2go: please update gofmt

Now the translator rejects the following code with generic.go2:10:20: expected operand, found 'type' (and 4 more errors)

type genericStream[type T any] struct {
    prevReq  chan struct{}
    prevData chan T
    nextReq  chan struct{}
    nextData chan T
}

func newGenericStream[type T any](gs *genericStream[T]) *genericStream[T] {
    return &genericStream[T]{
        prevReq:  gs.nextReq,
        prevData: gs.nextData,
        nextReq:  make(chan struct{}),
        nextData: make(chan T), 
    }   
}

So I just modified like this:

type genericStream[T any] struct {
    prevReq  chan struct{}
    prevData chan T
    nextReq  chan struct{}
    nextData chan T
}

func newGenericStream[T any](gs *genericStream[T]) *genericStream[T] {
    return &genericStream[T]{
        prevReq:  gs.nextReq,
        prevData: gs.nextData,
        nextReq:  make(chan struct{}),
        nextData: make(chan T), 
    }   
}

Now the translator translate this code, but gofmt will insert the deleted type again.

gofmt is important because it is the only tool to format *.go2 files.

Or this might be an issue for the translator.

closed time in a month

YoshikiShibata

issue commentgolang/go

cmd/go2go: please update gofmt

This should be fixed now in the dev.go2go branch with https://golang.org/cl/250998.

YoshikiShibata

comment created time in a month

issue commentgolang/go

cmd/go2go: please update gofmt

Thanks for this issue. I missed that. Will take care of this today or tomorrow.

YoshikiShibata

comment created time in a month

issue closedgolang/go

cmd/go2go: constraint type inference fails

The "Element constraint example" in the "Constraint type inference" section of the Type Parameters Draft Design (here) fails when run in the go2go playground: https://go2goplay.golang.org/p/VBEVxYVbF62

package main

import (
	"fmt"
)

type Number interface {
	type int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, uintptr, float32, float64
}

type MySlice []int

type SC[type E] interface {
	type []E
}

func DoubleDefined[type S SC[E], E Number](s S) S {
	r := make(S, len(s))
	for i, v := range s {
		r[i] = v + v
	}
	return r
}

func main() {
	
	// Expicit types work fine
	fmt.Println(DoubleDefined[MySlice, int](MySlice{1}))

	// Constraint type inference does not work?
	fmt.Println(DoubleDefined(MySlice{1}))
}

Output:

type checking failed for main
prog.go2:31:38: cannot infer E (prog.go2:17:34) ([main.MySlice <nil>])

The failure is in the second call to DoubleDefined, which is supposed to work according to the design. This is the point of the design doc example.

closed time in a month

JakeMont

issue commentgolang/go

cmd/go2go: constraint type inference fails

Fixed in the dev.go2go branch. Will come to the playground sometime soon.

JakeMont

comment created time in a month

issue commentgolang/go

cmd/go2go: constraint type inference fails

@iant: The go2go tool needs to set types.Config.InferFromConstraints to true, otherwise constraint type inference is not enabled.

JakeMont

comment created time in a month

issue commentgolang/go

cmd/go2go: constraint type inference fails

Interestingly this works fine when running this example in the type checker test harness, but not when running it outside. Investigating.

JakeMont

comment created time in a month

issue commentgolang/go

go/parser: feature request: parse declarations only

As @josharian has already observed, it's not trivial to "skip" over the contents of function bodies; i.e., at least if we don't know if they are correct. If we know that the code is correct, one could accelerate the parsing of function bodies by only counting opening/closing braces (they have to match up); but one would still have to read and tokenize the source text. One could do a little experiment and see what the performance difference would be, but it may not matter in the overall application (presumably, the result of parsing is used somehow).

@matthewmueller Is parsing a particularly time-consuming component of your application?

matthewmueller

comment created time in a month

issue commentgolang/go

cmd/compile: cannot handle alias type declaration

We have lived with this for a while now, it's unfortunate but seems not urgent. This will have to wait for the major type-checker overhaul that we hope to do if we go forward with generics.

griesemer

comment created time in a month

issue commentgolang/go

cmd/compile: unsafe.Pointer not treated as a pointer for embedding

Appears fixed per the above comment. Verified in latest playground. Closing.

griesemer

comment created time in a month

issue closedgolang/go

cmd/compile: unsafe.Pointer not treated as a pointer for embedding

<pre><a href="http://play.golang.org/p/YhdG1ZoVzp">http://play.golang.org/p/YhdG1ZoVzp</a>

Per the spec: "An embedded type must be specified as a type name T or as a pointer to a non-interface type name *T, and T itself may not be a pointer type." ( <a href="http://tip.golang.org/ref/spec#Struct_types">http://tip.golang.org/ref/spec#Struct_types</a> )

gc issues an error for line 9 (as expected), but not for line 10. Arguably, an unsafe.Pointer is a pointer and thus line 10 should not be legal.

The spec is not very clear about whether an unsafe.Pointer should act like a pointer in these situations, but:

  1. The documentation (by pseudo code) defines unsafe.Pointer as *ArbitraryType ( <a href="http://tip.golang.org/ref/spec#Package_unsafe">http://tip.golang.org/ref/spec#Package_unsafe</a> )

  2. For the purposes of method receivers, they are treated as pointers (see <a href="https://golang.org/issue/6116">issue #6116</a>)

  3. It's ok to assign nil to it (see line 15 of the above code).

  4. It's called a "Pointer".</pre>

closed time in a month

griesemer

issue commentgolang/go

proposal: Go 2 review meeting minutes

2020-08-11 / @iant

  • #40349 Go 2: add a "scope lifting" operator ^ for short variable declarations in if and for statements
    • closed (dup of #377 which expresses similar ideas)
  • #40353 Go 2: multivalue switch
    • likely decline, final call for comments
  • #40387 Go 2: accept multiple return values as the last arguments to function calls
    • likely decline, final call for comments
  • #40462 Go 2: allow fallthrough in type switches
    • likely decline, final call for comments
griesemer

comment created time in a month

issue closedgolang/go

cmd/go2go: unhelpful error message with generic map key type

For this test case:

package p

type Set[type T] map[T]bool

var V Set[func()]

the type checker reports

foo.go2:3:22: invalid map key type T

This is accurate but cryptic. It would be better if the error message said something like map key type T does not have comparable constraint.

CC @griesemer

closed time in a month

ianlancetaylor

issue commentgolang/go

cmd/go2go: unhelpful error message with generic map key type

Fixed by https://golang.org/cl/247258.

ianlancetaylor

comment created time in a month

issue closedgolang/go

cmd/go2go: assertion failed in unifier.nify

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version devel +34f76220c3 Sat Jul 4 04:55:49 2020 +0000 windows/amd64 </pre>

Does this issue reproduce with the latest release?

n/a

What operating system and processor architecture are you using (go env)?

  • Go2go playground
  • windows/amd64

What did you do?

https://go2goplay.golang.org/p/JXCEVdUcw-2

What did you expect to see?

Successful compilation or some error. I don't know should or should't this example compile, but type checker should not panic.

What did you see instead?

Stack trace:

panic: assertion failed [recovered]
	panic: assertion failed

goroutine 1 [running]:
go/types.(*Checker).handleBailout(0xc0001046c0, 0xc000077be0)
	G:/workspace/exprm/go/src/go/types/check.go:251 +0x9f
panic(0x101ff20, 0x10b5700)
	G:/workspace/exprm/go/src/runtime/panic.go:969 +0x176
go/types.assert(...)
	G:/workspace/exprm/go/src/go/types/errors.go:19
go/types.(*unifier).nify(0xc000052780, 0x10c17a0, 0xc00003eba0, 0x10c1200, 0xc00007e2d0, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/unify.go:368 +0x18e5
go/types.(*unifier).nify(0xc000052780, 0x10c15c0, 0xc00014e440, 0x10c15c0, 0xc00014ed00, 0x0, 0xf09093)
	G:/workspace/exprm/go/src/go/types/unify.go:261 +0xd07
go/types.(*unifier).nify(0xc000052780, 0x10c1340, 0xc00003eae0, 0x10c1340, 0xc00003f740, 0x0, 0xc000052780)
	G:/workspace/exprm/go/src/go/types/unify.go:278 +0xb3f
go/types.(*unifier).unify(0xc000052780, 0x10c1340, 0xc00003eae0, 0x10c1340, 0xc00003f740, 0xc00000a650)
	G:/workspace/exprm/go/src/go/types/unify.go:38 +0x65
go/types.(*Checker).missingMethod(0xc0001046c0, 0x10c1200, 0xc00007e2d0, 0xc00010a900, 0xc00014ec01, 0x10c10c0, 0xc00010a900)
	G:/workspace/exprm/go/src/go/types/lookup.go:418 +0x393
go/types.(*Checker).instantiate(0xc0001046c0, 0x306, 0x10c1340, 0xc00003f1a0, 0xc000153280, 0x4, 0x4, 0xc000010880, 0x4, 0x4, ...)
	G:/workspace/exprm/go/src/go/types/subst.go:165 +0x8b6
go/types.(*Checker).call(0xc0001046c0, 0xc000153140, 0xc00003d680, 0x1230e20)
	G:/workspace/exprm/go/src/go/types/call.go:116 +0x339
go/types.(*Checker).exprInternal(0xc0001046c0, 0xc000153140, 0x10bd540, 0xc00003d680, 0x0, 0x0, 0x10c12a0)
	G:/workspace/exprm/go/src/go/types/expr.go:1576 +0x1df0
go/types.(*Checker).rawExpr(0xc0001046c0, 0xc000153140, 0x10bd540, 0xc00003d680, 0x0, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/expr.go:1033 +0xc7
go/types.(*Checker).exprOrType(0xc0001046c0, 0xc000153140, 0x10bd540, 0xc00003d680)
	G:/workspace/exprm/go/src/go/types/expr.go:1724 +0x5c
go/types.(*Checker).call(0xc0001046c0, 0xc000153140, 0xc00003d740, 0x230dcfab748)
	G:/workspace/exprm/go/src/go/types/call.go:17 +0x78
go/types.(*Checker).exprInternal(0xc0001046c0, 0xc000153140, 0x10bd540, 0xc00003d740, 0x0, 0x0, 0x38)
	G:/workspace/exprm/go/src/go/types/expr.go:1576 +0x1df0
go/types.(*Checker).rawExpr(0xc0001046c0, 0xc000153140, 0x10bd540, 0xc00003d740, 0x0, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/expr.go:1033 +0xc7
go/types.(*Checker).stmt(0xc0001046c0, 0x0, 0x10bd7c0, 0xc000032e30)
	G:/workspace/exprm/go/src/go/types/stmt.go:330 +0x3e78
go/types.(*Checker).stmtList(0xc0001046c0, 0x0, 0xc000032e40, 0x1, 0x1)
	G:/workspace/exprm/go/src/go/types/stmt.go:125 +0xd6
go/types.(*Checker).funcBody(0xc0001046c0, 0xc00003e720, 0xc00000a6d8, 0x4, 0xc00003f440, 0xc000067e90, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/stmt.go:42 +0x268
go/types.(*Checker).funcDecl.func1()
	G:/workspace/exprm/go/src/go/types/decl.go:792 +0x6e
go/types.(*Checker).processDelayed(0xc0001046c0, 0x0)
	G:/workspace/exprm/go/src/go/types/check.go:315 +0x45
go/types.(*Checker).checkFiles(0xc0001046c0, 0xc000077cb8, 0x1, 0x1, 0x0, 0x0)
	G:/workspace/exprm/go/src/go/types/check.go:283 +0x14d
go/types.(*Checker).Files(...)
	G:/workspace/exprm/go/src/go/types/check.go:256
go/types.(*Config).Check(0xc00003d780, 0xc00000a4d0, 0x4, 0xc00003c280, 0xc000077cb8, 0x1, 0x1, 0xc000041360, 0x0, 0xc000142000, ...)
	G:/workspace/exprm/go/src/go/types/api.go:387 +0x188
go/go2go.RewriteBuffer(0xc00003e2a0, 0xc00000e360, 0x26, 0xc000144000, 0x355, 0x555, 0x0, 0xc000066ba0, 0xc000066b70, 0xc000066b40, ...)
	G:/workspace/exprm/go/src/go/go2go/go2go.go:137 +0x25b
main.translateFile(0xc00003e2a0, 0xc00000e360, 0x26)
	G:/workspace/exprm/go/src/cmd/go2go/translate.go:26 +0xb0
main.main()
	G:/workspace/exprm/go/src/cmd/go2go/main.go:65 +0x30a

closed time in a month

tdakkota

issue commentgolang/go

cmd/go2go: assertion failed in unifier.nify

Fixed by https://golang.org/cl/247498.

tdakkota

comment created time in a month

issue commentgolang/go

go/printer: comments were unexpected inserted in `import` decl

Just seeing this (I was on vacation last week). It's too later for 1.15.

oraluben

comment created time in a month

issue openedgolang/go

cmd/go2go: missing error for use of uninstantiated type argument

package p

type A[type T] int

func f[type P]()

func _() {
	_ = f[A]
}

passes type-checking without error. But it should not be possible to instantiate f[A] with an uninstantiated A.

Follow-up on #40038.

created time in 2 months

issue openedgolang/go

cmd/go2go: generated code leads to cmd/compile internal error

Extracted from crash 9 of #39634 :

https://go2goplay.golang.org/p/-YZdFhVx8UX

cc: @ianlancetaylor

created time in 2 months

issue commentgolang/go

cmd/go2go: decide what unsafe.Sizeof/Alignof mean when applied to values of type parameter type

Correct. One could convert to a T and check if it's not 0, but then one might just as well choose the 2nd solution. There's a loop, but it iterates only 4x at most. It could be unrolled easily if speed mattered. It may be faster than the type switch.

AndrewWPhillips

comment created time in 2 months

issue commentgolang/go

cmd/go2go: decide what unsafe.Sizeof/Alignof mean when applied to values of type parameter type

This code implements minInt in two ways, both without using unsafe.

AndrewWPhillips

comment created time in 2 months

issue commentgolang/go

cmd/go2go: cannot use x (variable of type X(T)) as X(T) value in assignment

This appears to be an evaluation/type-checking ordering problem caused by the mutually referencing types. Moving the declaration of type Y to the beginning "solves" the problem: https://go2goplay.golang.org/p/h4tcdkyvm2N .

This (and related issues) require some significant re-engineering of the type-checker. Probably won't address in the prototype, in favor of spending engineering effort on a real implementation. Leaving open so we have a test case.

Merovius

comment created time in 2 months

issue commentgolang/go

cmd/go2go: decide what unsafe.Sizeof/Alignof mean when applied to values of type parameter type

@AndrewWPhillips Indeed! I apologize for the unqualified rushed judgement.

I've checked out that older version and looked at the type-checker and the generated code. It turns out the unsafe.Sizeof wasn't implemented for type of type parameter type (as suspected), but there was also no panic call to remind me that it was not yet implemented, and thus it didn't crash. Instead it used the fallback value, which happens to be the word size (== 8). So, while type-checking was not crashing, it definitively was incorrect. The translator portion of the go2go tool doesn't consider the fact that unsafe.Sizeof(T(0)) is deemed a constant value by the type-checker and always generates code to call unsafe.Sizeof(T(0)) rather than always producing the constant 8. Because the tool instantiates (== generates) the function f for each possible type, approximately resulting in a f_int, f_byte, and f_uint64 version of f, it happened to work after all. One might even say it worked because we hadn't implemented it yet...

Anyway, mystery solved. Thanks for pointing this out.

AndrewWPhillips

comment created time in 2 months

issue commentgolang/go

proposal: Go 2 review meeting minutes

2020-07-21 / @bradfitz, @griesemer, @iant

  • #39372 selector-specific control flow & gofmt rules to improve error-checking readability
    • closed (no further comments)
  • #39530 Go 2: permit file based overloading of unexported names
    • closed (no change in consensus)
  • #39799 Go 2: interface methods
    • likely decline, final call for comments
griesemer

comment created time in 2 months

IssuesEvent

issue commentgolang/go

cmd/go2go: panic taking size of parameter type

Reopened and retitled for decision making.

AndrewWPhillips

comment created time in 2 months

issue commentgolang/go

cmd/go2go: panic taking size of parameter type

@ianlancetaylor pointed out that one could define unsafe.Sizeof such that it would not return a compile-time constant if the argument is of type parameter type. That would certainly be trivial from a type-checker's point of view but would break an assumption we currently have for unsafe.Sizeof (but not permitting it would also break an assumption, so perhaps that's the way to go after all).

AndrewWPhillips

comment created time in 2 months

issue commentgolang/go

cmd/go2go: failure to compile type parameter names that shadow dot-imported identifiers

This is unrelated to the name of the type parameter, or generic code for that matter. This code has the same problem.

mdempsky

comment created time in 2 months

issue commentgolang/go

cmd/go2go: failure to compile type parameter names that shadow dot-imported identifiers

This type-checks fine. Looks like an issue with the translator.

mdempsky

comment created time in 2 months

issue commentgolang/go

cmd/go2go: unclear error message in embedded type lists

Just for the record, the problem is not that int32 is repeated in both interfaces, the problem is that int is not repeated in both interfaces: When interfaces are embedded, all the type lists are intersected. This way we can guarantee that if a type T satisfies an interface that embeds an interface E, T also satisfies E.

Agreed that we could use a better error message. Not urgent.

komuw

comment created time in 2 months

issue closedgolang/go

cmd/go2go: panic taking size of parameter type

What version of Go are you using (go version)?

<pre> $ go version go version devel +893c5ec17b Thu Jul 16 21:30:46 2020 +0000 windows/amd64 </pre>

Does this issue reproduce with the latest release?

N/A

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env set GO111MODULE= set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\Andre\AppData\Local\go-build set GOENV=C:\Users\Andre\AppData\Roaming\go\env set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GOMODCACHE=C:\Users\Andre\go\pkg\mod set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=C:\Users\Andre\go set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=C:\Users\Andre\goroot set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=C:\Users\Andre\goroot\pkg\tool\windows_amd64 set GCCGO=gccgo set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD= set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Andrew\AppData\Local\Temp\go-build443956446=/tmp/go-build -gno-record-g cc-switches

</pre></details>

What did you do?

package main

import "unsafe"

type HasZero interface {
	type int, int8 // etc
}

func f(type T HasZero)() {
	const sz = unsafe.Sizeof(T(0))
}

$ go tool go2go build

What did you expect to see?

build succeeds (or perhaps build error message)

What did you see instead?

panic: Sizeof unimplemented for type sum [recovered] panic: Sizeof unimplemented for type sum

goroutine 1 [running]: go/types.(*Checker).handleBailout(0xc00009e3c0, 0xc0000cb9f8) /path/goroot/src/go/types/check.go:252 +0xa5 panic(0xe21f40, 0xeb74e0) /path/goroot/src/runtime/panic.go:969 +0x176 go/types.(*StdSizes).Sizeof(0xc0000a2280, 0xec3700, 0xc0000f0600, 0xc0000f06c0) /path/goroot/src/go/types/sizes.go:152 +0x218 go/types.(*Config).sizeof(0xc0000f0500, 0xec3700, 0xc0000f0600, 0x0) /path/goroot/src/go/types/sizes.go:258 +0xa2 go/types.(*Checker).builtin(0xc00009e3c0, 0xc0000f0680, 0xc0000f0440, 0x11, 0xc000020800) /path/goroot/src/go/types/builtins.go:642 +0x3997 go/types.(*Checker).call(0xc00009e3c0, 0xc0000f0680, 0xc0000f0440, 0x30) /path/goroot/src/go/types/call.go:63 +0xdb0 go/types.(*Checker).exprInternal(0xc00009e3c0, 0xc0000f0680, 0xebf680, 0xc0000f0440, 0x0, 0x0, 0x2b) /path/goroot/src/go/types/expr.go:1603 +0x1df0 go/types.(*Checker).rawExpr(0xc00009e3c0, 0xc0000f0680, 0xebf680, 0xc0000f0440, 0x0, 0x0, 0x0) /path/goroot/src/go/types/expr.go:1033 +0xc7 go/types.(*Checker).expr(0xc00009e3c0, 0xc0000f0680, 0xebf680, 0xc0000f0440) /path/goroot/src/go/types/expr.go:1726 +0x5c go/types.(*Checker).constDecl(0xc00009e3c0, 0xc0000d2480, 0x0, 0x0, 0xebf680, 0xc0000f0440) /path/goroot/src/go/types/decl.go:419 +0x192 go/types.(*Checker).declStmt(0xc00009e3c0, 0xebfa00, 0xc0000f0480) /path/goroot/src/go/types/decl.go:832 +0xe5 go/types.(*Checker).stmt(0xc00009e3c0, 0x0, 0xebf7c0, 0xc0000885d0) /path/goroot/src/go/types/stmt.go:319 +0x3886 go/types.(*Checker).stmtList(0xc00009e3c0, 0x0, 0xc0000885e0, 0x1, 0x1) /path/goroot/src/go/types/stmt.go:125 +0xd6 go/types.(*Checker).funcBody(0xc00009e3c0, 0xc0000d23c0, 0xfefe10, 0x1, 0xc0000d2420, 0xc0000b8e10, 0x0, 0x0) /path/goroot/src/go/types/stmt.go:42 +0x268 go/types.(*Checker).funcDecl.func1() /path/goroot/src/go/types/decl.go:792 +0x6e go/types.(*Checker).processDelayed(0xc00009e3c0, 0x0) /path/goroot/src/go/types/check.go:327 +0x45 go/types.(*Checker).checkFiles(0xc00009e3c0, 0xc0000cc0a0, 0x1, 0x1, 0x0, 0x0) /path/goroot/src/go/types/check.go:295 +0x20d go/types.(*Checker).Files(...) /path/goroot/src/go/types/check.go:257 go/types.(*Config).Check(0xc0000f0500, 0xc0000a2528, 0x4, 0xc0000f0240, 0xc0000cc0a0, 0x1, 0x1, 0xc0000d5310, 0x1, 0x1, ...) /path/goroot/src/go/types/api.go:387 +0x188 go/go2go.rewriteFilesInPath(0xc0000d2240, 0x0, 0x0, 0xe6fac3, 0x1, 0xc0000b8c60, 0x1, 0x3, 0x0, 0x0, ...) /path/goroot/src/go/go2go/go2go.go:93 +0x4f0 go/go2go.rewriteToPkgs(0xc0000d2240, 0x0, 0x0, 0xe6fac3, 0x1, 0xc0000985c0, 0xc0000b8ab0, 0xc0000b8a80, 0xc0000b8a50, 0xc0000b8a20) /path/goroot/src/go/go2go/go2go.go:46 +0x16e go/go2go.Rewrite(...) /path/goroot/src/go/go2go/go2go.go:30 main.translate(0xc0000d2240, 0xe6fac3, 0x1) /path/goroot/src/cmd/go2go/translate.go:15 +0x4e main.main() /path/goroot/src/cmd/go2go/main.go:78 +0xa0c

closed time in 2 months

AndrewWPhillips

issue commentgolang/go

cmd/go2go: panic taking size of parameter type

I will "fix this" for now by reporting an error. We can revisit if we have a better idea of what the right approach is.

AndrewWPhillips

comment created time in 2 months

issue commentgolang/go

cmd/go2go: panic taking size of parameter type

@AndrewWPhillips I didn't "work" before - it just may not have crashed.

The question is: What does that unsafe.Sizeof(x) where x is of a type parameter type even mean? unsafe.Sizeof is a compile time constant, it must be determined when the function that contains it is compiled. I can see how we could make this work when the associated constraint contains a type list, but if there's more than one type in the type list (or they have different sizes) it's going to be very hard to maintain that "compile-time" constant aspect. We don't have any facility for something like this in the compiler at the moment, and it's not clear (to me) that we need it.

AndrewWPhillips

comment created time in 2 months

issue closedgolang/go

cmd/gofmt: don't remove spaces when combining binary and unary *

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

go1.14.4

Problem

I understand that gofmt will try to remove spaces between operator and operand, so that it's easier to tell the association. However, this creates weird situations when the star operator is involved with pointers. For example:

x := 10
p1 := &x
p2 := &x
fmt.Println(10 * *p1 * *p2)

works as expected, but if we add a 1 in the last line:

x := 10
p1 := &x
p2 := &x
fmt.Println(10**p1**p2 + 1)

where the 10 **p1 **p2 would be very easily confused as an exponential operator - which golang doesn't have.

closed time in 2 months

peidaqi

issue commentgolang/go

cmd/gofmt: don't remove spaces when combining binary and unary *

If we rewrite your example as desired, we get:

fmt.Println(10 * *p1 * *p2 + 1)

which is better for the multiplications, but worse for the addition as it lost its difference from the multiplications which have higher precedence. As has been pointed out above, this was discussed almost 10 years ago and we decided to leave it alone. The better solution is to introduce parentheses to increase readability when it's problematic. Also, this is not a very common situation.

peidaqi

comment created time in 2 months

issue commentgolang/go

proposal: Go 2 review meeting minutes

An update regarding the Go 2 proposal review process:

Over the last couple of years, three of us (@bradfitz, @griesemer, @ianlancetaylor) have been meeting regularly for approx. one hour each week to review outstanding Go 2 proposals. More recently, we have started documenting this process in this issue with weekly updates. The goal was and is to identify promising ideas, weed out less suitable proposals, and generally shepherd along issues so they all get some attention eventually.

As of late, most proposals we are seeing suggest changes to the language. Any language change needs to be fully fleshed out and bring a significant benefit. Yet we are not planning to change the language beyond the ongoing discussion on generics.

In turn, our proposal review meetings have become somewhat scripted and unproductive: We spend much of the time trying to understand or identify issues with (language) proposals so we can make progress or close them for good reason, yet there is no urgent need to make progress with most of them in the first place. In a sense, our goal to ensure all proposals are shepherded along was probably misdirected.

Going forward, we will try a different approach: Instead of trying to process all incoming proposals, we will hand-pick promising candidates as time permits. Similarly, proposals which we don't see going anywhere we will close quickly without too much discussion. On the flipside, we may ignore proposals for extended periods of time. When we do address a proposal, we will continue to report it in this issue. To summarize: We are open to new ideas but we are in no hurry to make changes.

We hope this will free up time to work on more pressing issues. With respect to language changes, most will have to wait until a final decision on generics is made: we don't want unrelated changes to interfere with the generics design. And even after generics, the emphasis will be on fine-tuning the language and rounding it out where there are "holes", rather than radical changes. Given our growing code and user base, we must prize backward-compatibility and stability over personal convenience or preference.

The Go 2 proposal review team.

griesemer

comment created time in 2 months

issue commentgolang/go

proposal: Go 2 review meeting minutes

2020-07-14 / @bradfitz, @griesemer, @iant

  • #39454 Go 2: change chan syntax from <- to "in out"
    • closed (no change in consensus)
  • #19367 unsafe: add Slice and String types, conversions to replace reflect.{Slice,String}Header
    • moved out of Go2 proposal, made a regular proposal
griesemer

comment created time in 2 months

issue commentgolang/go

cmd/go2go: embedded types ignored in interface implementation

This code passes the type-checker. Likely an issue with the translator phase.

JavierZunzunegui

comment created time in 2 months

issue commentgolang/go

cmd/go2go: embedded types ignored in interface implementation

@mmaedel Done.

JavierZunzunegui

comment created time in 2 months

issue commentgolang/go

proposal: Go 2 review meeting minutes

2020-07-07 / @bradfitz, @griesemer, @iant

  • #38753 Go 2: handle type conversion of interface-slices similar to interfaces
    • closed (no change in concensus)
griesemer

comment created time in 3 months

issue commentgolang/go

cmd/go2go: unclear error message for type parameter

@crawshaw The problem here is that map[string]X(int) must be parsed as (map[string]X)(int) for backward-compatibility; i.e., is looks like a conversion. To make it work, we need extra parentheses, as in: map[string](X(int)).

Now, in "type context", we know that it cannot be a conversion and we can do the right thing. For instance, var _ map[string]X(int) doesn't require those extra parentheses.

Arguably, in the make call above, the map type is in "type context". But we don't know this until type-checking time: we cannot know that make actually refers to the built-in make function and not some user-defined version that may possibly be defined in another file of the same package. Thus, the parser cannot know better. The type-checker may be able to re-associate the AST but it's tricky (I haven't thought that through in detail). For the same reason it's not easily possible to provide a better error message: The AST is a call/conversion node, where the LHS is map[string]X and the argument is int - when we look at X we're very far removed from the respective context.

This, and many other problems would go away if our keyboards had one more style of easily accessible parentheses...

crawshaw

comment created time in 3 months

issue closedgolang/go

cmd/go2go: "receiver type inference failed" panic on invalid type

commit 34f76220c32bfe7766ca074d5ae69d6f716b9b2c

The following program panics instead of producing a type-check error.

package main

func main() {
	NewS().M()
}

type S struct {}

func NewS(type T)() *S {
	return nil
}

func (c *S(T)) M() {}

The panic traceback is:

panic: internal error: receiver type parameter inference failed [recovered]
	panic: internal error: receiver type parameter inference failed

goroutine 1 [running]:
go/types.(*Checker).handleBailout(0xc00007c7e0, 0xc0000cbbe0)
	/usr/local/go-faketime/src/go/types/check.go:251 +0x98
panic(0x6498a0, 0x6db6e0)
	/usr/local/go-faketime/src/runtime/panic.go:969 +0x175
go/types.(*Checker).selector(0xc00007c7e0, 0xc000072740, 0xc00000c240)
	/usr/local/go-faketime/src/go/types/call.go:534 +0x25b7
go/types.(*Checker).exprInternal(0xc00007c7e0, 0xc000072740, 0x6e3a20, 0xc00000c240, 0x0, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/expr.go:1320 +0x29cc
go/types.(*Checker).rawExpr(0xc00007c7e0, 0xc000072740, 0x6e3a20, 0xc00000c240, 0x0, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/expr.go:1033 +0xc5
go/types.(*Checker).exprOrType(0xc00007c7e0, 0xc000072740, 0x6e3a20, 0xc00000c240)
	/usr/local/go-faketime/src/go/types/expr.go:1717 +0x55
go/types.(*Checker).call(0xc00007c7e0, 0xc000072740, 0xc0000722c0, 0x0)
	/usr/local/go-faketime/src/go/types/call.go:17 +0x69
go/types.(*Checker).exprInternal(0xc00007c7e0, 0xc000072740, 0x6e32a0, 0xc0000722c0, 0x0, 0x0, 0x38)
	/usr/local/go-faketime/src/go/types/expr.go:1569 +0x1dd0
go/types.(*Checker).rawExpr(0xc00007c7e0, 0xc000072740, 0x6e32a0, 0xc0000722c0, 0x0, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/expr.go:1033 +0xc5
go/types.(*Checker).stmt(0xc00007c7e0, 0x0, 0x6e3520, 0xc00001c500)
	/usr/local/go-faketime/src/go/types/stmt.go:330 +0x3e78
go/types.(*Checker).stmtList(0xc00007c7e0, 0x0, 0xc00001c510, 0x1, 0x1)
	/usr/local/go-faketime/src/go/types/stmt.go:125 +0xd1
go/types.(*Checker).funcBody(0xc00007c7e0, 0xc00004a4e0, 0xc00001a3e8, 0x4, 0xc00004a660, 0xc000010b70, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/stmt.go:42 +0x257
go/types.(*Checker).funcDecl.func1()
	/usr/local/go-faketime/src/go/types/decl.go:790 +0x67
go/types.(*Checker).processDelayed(0xc00007c7e0, 0x0)
	/usr/local/go-faketime/src/go/types/check.go:315 +0x3e
go/types.(*Checker).checkFiles(0xc00007c7e0, 0xc00003dcb8, 0x1, 0x1, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/check.go:283 +0x145
go/types.(*Checker).Files(...)
	/usr/local/go-faketime/src/go/types/check.go:256
go/types.(*Config).Check(0xc0000724c0, 0xc00001a3e0, 0x4, 0xc000072240, 0xc00003dcb8, 0x1, 0x1, 0xc000055360, 0x0, 0x4b702f, ...)
	/usr/local/go-faketime/src/go/types/api.go:387 +0x188
go/go2go.RewriteBuffer(0xc00004a3c0, 0x7ffc90c44dec, 0x1e, 0xc0000ba000, 0x7b, 0x27b, 0x0, 0xc000010a50, 0xc000010a20, 0xc0000109f0, ...)
	/usr/local/go-faketime/src/go/go2go/go2go.go:137 +0x24f
main.translateFile(0xc00004a3c0, 0x7ffc90c44dec, 0x1e)
	/usr/local/go-faketime/src/cmd/go2go/translate.go:26 +0xa9
main.main()
	/usr/local/go-faketime/src/cmd/go2go/main.go:65 +0x2f6

closed time in 3 months

rogpeppe

issue commentgolang/go

cmd/go2go: "receiver type inference failed" panic on invalid type

Fixed on dev.go2go.

rogpeppe

comment created time in 3 months

issue commentgolang/go

cmd/go2go: generic function type assignment fails to type check correctly

One of the functions is not properly instantiated.

rogpeppe

comment created time in 3 months

issue closedgolang/go

cmd/go2go: unification panic when type switching on uninstantiated type

The following program panics when unifying instead of complaining about the type switch on the uninstantiated generic type.

package main

func main() {
	var x interface{}
	switch t := x.(type) {
	case *S:
		t.M()
	}
}

type S(type T) struct {}

func (i *S(T)) M() {
	panic("unreachable")
}

The panic traceback is:

panic: assertion failed [recovered]
	panic: assertion failed

goroutine 1 [running]:
go/types.(*Checker).handleBailout(0xc00007c5a0, 0xc0000cbbe0)
	/usr/local/go-faketime/src/go/types/check.go:251 +0x98
panic(0x6498a0, 0x6db5e0)
	/usr/local/go-faketime/src/runtime/panic.go:969 +0x175
go/types.assert(...)
	/usr/local/go-faketime/src/go/types/errors.go:19
go/types.(*unifier).nify(0xc0000903c0, 0x6e6f20, 0xc00004a6c0, 0x6e6980, 0xc00007a240, 0x0, 0x6773e0)
	/usr/local/go-faketime/src/go/types/unify.go:351 +0x18c5
go/types.(*unifier).nify(0xc0000903c0, 0x6e6a20, 0xc00000c600, 0x6e6a20, 0xc00000c6c0, 0x0, 0x40f732)
	/usr/local/go-faketime/src/go/types/unify.go:233 +0xfca
go/types.(*unifier).unify(...)
	/usr/local/go-faketime/src/go/types/unify.go:38
go/types.(*Checker).infer(0xc00007c5a0, 0x80, 0xc00000e0e8, 0x1, 0x1, 0xc0000c8f78, 0xc0000c8f30, 0x1, 0x1, 0xc00001a470, ...)
	/usr/local/go-faketime/src/go/types/infer.go:52 +0x36a
go/types.(*Checker).selector(0xc00007c5a0, 0xc0000727c0, 0xc00000c300)
	/usr/local/go-faketime/src/go/types/call.go:529 +0xdfa
go/types.(*Checker).exprInternal(0xc00007c5a0, 0xc0000727c0, 0x6e3a20, 0xc00000c300, 0x0, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/expr.go:1320 +0x29cc
go/types.(*Checker).rawExpr(0xc00007c5a0, 0xc0000727c0, 0x6e3a20, 0xc00000c300, 0x0, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/expr.go:1033 +0xc5
go/types.(*Checker).exprOrType(0xc00007c5a0, 0xc0000727c0, 0x6e3a20, 0xc00000c300)
	/usr/local/go-faketime/src/go/types/expr.go:1717 +0x55
go/types.(*Checker).call(0xc00007c5a0, 0xc0000727c0, 0xc000072300, 0xc00007cea8)
	/usr/local/go-faketime/src/go/types/call.go:17 +0x69
go/types.(*Checker).exprInternal(0xc00007c5a0, 0xc0000727c0, 0x6e32a0, 0xc000072300, 0x0, 0x0, 0x38)
	/usr/local/go-faketime/src/go/types/expr.go:1569 +0x1dd0
go/types.(*Checker).rawExpr(0xc00007c5a0, 0xc0000727c0, 0x6e32a0, 0xc000072300, 0x0, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/expr.go:1033 +0xc5
go/types.(*Checker).stmt(0xc00007c5a0, 0x1, 0x6e3520, 0xc00001c5a0)
	/usr/local/go-faketime/src/go/types/stmt.go:330 +0x3e78
go/types.(*Checker).stmtList(0xc00007c5a0, 0x1, 0xc00001c5b0, 0x1, 0x1)
	/usr/local/go-faketime/src/go/types/stmt.go:125 +0xd1
go/types.(*Checker).stmt(0xc00007c5a0, 0x0, 0x6e3c20, 0xc000010c60)
	/usr/local/go-faketime/src/go/types/stmt.go:662 +0x1112
go/types.(*Checker).stmtList(0xc00007c5a0, 0x0, 0xc00000c320, 0x2, 0x2)
	/usr/local/go-faketime/src/go/types/stmt.go:125 +0xd1
go/types.(*Checker).funcBody(0xc00007c5a0, 0xc00004a4e0, 0xc00001a3e8, 0x4, 0xc00004a600, 0xc000010c90, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/stmt.go:42 +0x257
go/types.(*Checker).funcDecl.func1()
	/usr/local/go-faketime/src/go/types/decl.go:790 +0x67
go/types.(*Checker).processDelayed(0xc00007c5a0, 0x0)
	/usr/local/go-faketime/src/go/types/check.go:315 +0x3e
go/types.(*Checker).checkFiles(0xc00007c5a0, 0xc00003dcb8, 0x1, 0x1, 0x0, 0x0)
	/usr/local/go-faketime/src/go/types/check.go:283 +0x145
go/types.(*Checker).Files(...)
	/usr/local/go-faketime/src/go/types/check.go:256
go/types.(*Config).Check(0xc000072540, 0xc00001a3e0, 0x4, 0xc000072240, 0xc00003dcb8, 0x1, 0x1, 0xc000055360, 0x0, 0x4b702f, ...)
	/usr/local/go-faketime/src/go/types/api.go:387 +0x188
go/go2go.RewriteBuffer(0xc00004a3c0, 0x7ffd420a9dec, 0x1e, 0xc0000ba000, 0xa6, 0x2a6, 0x0, 0xc000010a50, 0xc000010a20, 0xc0000109f0, ...)
	/usr/local/go-faketime/src/go/go2go/go2go.go:137 +0x24f
main.translateFile(0xc00004a3c0, 0x7ffd420a9dec, 0x1e)
	/usr/local/go-faketime/src/cmd/go2go/translate.go:26 +0xa9
main.main()
	/usr/local/go-faketime/src/cmd/go2go/main.go:65 +0x2f6

closed time in 3 months

rogpeppe

issue commentgolang/go

cmd/go2go: unification panic when type switching on uninstantiated type

Fixed on dev.go2go.

rogpeppe

comment created time in 3 months

issue commentgolang/go

cmd/go2go: unification panic when type switching on uninstantiated type

Unrelated to crashes 24 or 25 of #39544.

rogpeppe

comment created time in 3 months

issue commentgolang/go

cmd/go2go: build tags not supported correctly

I don't know off-hand how much effort is needed to make this work, but we may decide to not do anything about it. Keep in mind this is a prototype to explore the generics mechanisms; anything and everything may change as we go forward.

rogpeppe

comment created time in 3 months

issue commentgolang/go

cmd/go2go: cannot use make(map[int]X) (value of type map[int]X) as map[int]X value in struct literal

@ianlancetaylor Not sure if this is still a type-checker issue or a translator issue at this point.

arl

comment created time in 3 months

IssuesEvent

issue commentgolang/go

cmd/go2go: cannot use make(map[int]X) (value of type map[int]X) as map[int]X value in struct literal

@arl, thanks for this. I admit I only tested type-checking for this case. Reopening.

arl

comment created time in 3 months

issue closedgolang/go

cmd/go2go: cannot use make(map[int]X) (value of type map[int]X) as map[int]X value in struct literal

What version of Go are you using (go version)?

<pre> $ go version go version devel +d014fca6d4 Wed Jul 1 20:30:10 2020 +0000 linux/amd64</pre>

Does this issue reproduce with the latest release?

It does with latest commit of the dev.go2go experimental branch: d014fca6d4

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/aurelien/.cache/go-build" GOENV="/home/aurelien/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/aurelien/godev/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/aurelien/godev" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/aurelien/dev/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/aurelien/dev/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build789085526=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

A bit of context: I'm currently experimenting with the generics draft by trying to use it to develop a generics cache library. I compacted the code into a single-file reproducer to make debugging easier but the actual code imports various packages, among which the list package of the dev.go2go source tree (generic replacement for container/list).

The original cache is based off a simple map where the value is a *list.Element(*entry(K).

package main

type (
	Element(type TElem) struct{}

	entry(type K comparable) struct{}

	Cache(type K comparable) struct {
		data map[K]*Element(*entry(K))
	}
)

func main() {
	_ = Cache(int){
		data: make(map[int](*Element(*entry(int)))), // cannot use make(map[int](*Element(*entry(int)))) (value of type map[int]*Element(*entry(int))) as map[int]*Element(*entry(int)) value in struct literal
	}
}

It does the same on the playground: https://go2goplay.golang.org/p/qoMgsPA5ifd

What did you expect to see?

a successful compilation since the provided map is, AFAICT, of the same type as the Cache.data type.

What did you see instead?

The error reported above:

cannot use make(map[int](*Element(*entry(int)))) (value of type map[int]*Element(*entry(int))) as map[int]*Element(*entry(int)) value in struct literal

closed time in 3 months

arl

issue commentgolang/go

cmd/go2go: cannot use make(map[int]X) (value of type map[int]X) as map[int]X value in struct literal

Definitely a type-checker failure.

arl

comment created time in 3 months

issue closedgolang/go

cmd/go2go: _ = interface{type int}(1) fails with a bad error message

Extracted from: https://twitter.com/hajimehoshi/status/1273094191686586374

At the moment we don't permit usage of interfaces with type lists outside constraints, but this shouldn't fail like this. At least there should be clearer error message, or better, we should permit this.

closed time in 3 months

griesemer

issue commentgolang/go

cmd/go2go: _ = interface{type int}(1) fails with a bad error message

Fixed on dev.go2go.

griesemer

comment created time in 3 months

issue closedgolang/go

cmd/go2go: assertion failed in go/types/subst.go: (makeSubstMap)

What version of Go are you using (go version)?

<pre> $ go version go version devel +6cf6bf162c Wed Jul 1 00:31:32 2020 +0000 linux/amd64 </pre>

Does this issue reproduce with the latest release?

It does with the latest commit, at time of writing, of the dev.go2go experimental branch: 6cf6bf162c

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/aurelien/.cache/go-build" GOENV="/home/aurelien/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/aurelien/dev/go2/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/aurelien/dev/go2" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/aurelien/dev/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/aurelien/dev/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build655914420=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

Running the following file:

package main

// entry stores cached entry key and value.
type entry(type K comparable, V any) struct {
	key   K
	value V

	// accessed is the number of nanoseconds elapsed between the cache epoch and the last time the key was accessed.
	accessed uint64
	// updated is the number of nanoseconds elapsed between the cache epoch and the last time the key was updated.
	updated uint64

	// hash of this key
	hash uint64
}

// any is a convenient type bounds.
type any interface{}

// policy is a cache eviction policy.
type policy(type K comparable, V any) interface {
	init(cache *Cache(K, V), maximumSize int)
	add(*entry(K, V)) *entry(K, V)
	del(*entry(K, V)) *entry(K, V)
}

// LRU is a least-frequently-used policy.
type LRU(type K comparable, V any) struct{}

func (p *LRU(K, V)) init(cache *Cache(K, V), maximumSize int) {}
func (p *LRU(K, V)) add(*entry(K, V)) *entry(K, V)            { return nil }
func (p *LRU(K, V)) del(*entry(K, V)) *entry(K, V)            { return nil }

type Cache(type K comparable, V any) struct {
	policy policy(K, V)
}

func NewCache(type K comparable, V any)(maxkeys uint64, p policy(K, V)) Cache(K, V) {
	return Cache(K, V){
		policy: p,
	}
}

func main() {
	lru := LRU(int, string){}
//	c := NewCache(int, string)(256, &lru) // ok: compiles and run
	c := NewCache(256, &lru) // nok: go2go panics
	_ = c
}

triggers:

$ go tool go2go run issue.go
panic: assertion failed [recovered]
        panic: assertion failed

goroutine 1 [running]:
go/types.(*Checker).handleBailout(0xc00011c5a0, 0xc0001879f8)
        /home/aurelien/dev/go/src/go/types/check.go:251 +0x98
panic(0x649860, 0x6db4a0)
        /home/aurelien/dev/go/src/runtime/panic.go:969 +0x175
go/types.assert(...)
        /home/aurelien/dev/go/src/go/types/errors.go:19
go/types.makeSubstMap(0xc000066ed0, 0x2, 0x2, 0xc000179080, 0x2, 0x2, 0xc000185c60)
        /home/aurelien/dev/go/src/go/types/subst.go:34 +0x2ae
go/types.(*Checker).infer.func1(0x696d0d, 0x4, 0x6e7020, 0xc000071200, 0x6e6b20, 0xc000179060, 0xc0001731c0)
        /home/aurelien/dev/go/src/go/types/infer.go:24 +0x95
go/types.(*Checker).infer(0xc00011c5a0, 0x51e, 0xc000066ed0, 0x2, 0x2, 0xc000178ec0, 0xc000067520, 0x2, 0x2, 0xc00011c5a0, ...)
        /home/aurelien/dev/go/src/go/types/infer.go:54 +0x435
go/types.(*Checker).arguments(0xc00011c5a0, 0xc000037480, 0xc0000711a0, 0xc000067520, 0x2, 0x2, 0x2)
        /home/aurelien/dev/go/src/go/types/call.go:319 +0x305
go/types.(*Checker).call(0xc00011c5a0, 0xc000173140, 0xc000037480, 0xc000172180)
        /home/aurelien/dev/go/src/go/types/call.go:117 +0x585
go/types.(*Checker).exprInternal(0xc00011c5a0, 0xc000173140, 0x6e33a0, 0xc000037480, 0x0, 0x0, 0x5883b2)
        /home/aurelien/dev/go/src/go/types/expr.go:1569 +0x1dd0
go/types.(*Checker).rawExpr(0xc00011c5a0, 0xc000173140, 0x6e33a0, 0xc000037480, 0x0, 0x0, 0x0)
        /home/aurelien/dev/go/src/go/types/expr.go:1033 +0xc5
go/types.(*Checker).multiExpr(0xc00011c5a0, 0xc000173140, 0x6e33a0, 0xc000037480)
        /home/aurelien/dev/go/src/go/types/expr.go:1692 +0x51
go/types.(*Checker).exprList(0xc00011c5a0, 0xc000066c80, 0x1, 0x1, 0x81bb00, 0x7f18ec9a0108, 0x0, 0x50, 0xc00017e6e0)
        /home/aurelien/dev/go/src/go/types/call.go:206 +0xb4
go/types.(*Checker).initVars(0xc00011c5a0, 0xc00000e468, 0x1, 0x1, 0xc000066c80, 0x1, 0x1, 0x0)
        /home/aurelien/dev/go/src/go/types/assignments.go:214 +0x94
go/types.(*Checker).shortVarDecl(0xc00011c5a0, 0x509, 0xc000066c40, 0x1, 0x1, 0xc000066c80, 0x1, 0x1)
        /home/aurelien/dev/go/src/go/types/assignments.go:326 +0x27e
go/types.(*Checker).stmt(0xc00011c5a0, 0x0, 0x6e31a0, 0xc0000374c0)
        /home/aurelien/dev/go/src/go/types/stmt.go:403 +0x351d
go/types.(*Checker).stmtList(0xc00011c5a0, 0x0, 0xc000037540, 0x3, 0x4)
        /home/aurelien/dev/go/src/go/types/stmt.go:125 +0xd1
go/types.(*Checker).funcBody(0xc00011c5a0, 0xc0000709c0, 0xc00002a75c, 0x4, 0xc000071620, 0xc0000115c0, 0x0, 0x0)
        /home/aurelien/dev/go/src/go/types/stmt.go:42 +0x257
go/types.(*Checker).funcDecl.func1()
        /home/aurelien/dev/go/src/go/types/decl.go:793 +0x67
go/types.(*Checker).processDelayed(0xc00011c5a0, 0x0)
        /home/aurelien/dev/go/src/go/types/check.go:315 +0x3e
go/types.(*Checker).checkFiles(0xc00011c5a0, 0xc00000e228, 0x1, 0x1, 0x0, 0x0)
        /home/aurelien/dev/go/src/go/types/check.go:283 +0x145
go/types.(*Checker).Files(...)
        /home/aurelien/dev/go/src/go/types/check.go:256
go/types.(*Config).Check(0xc000037580, 0xc00002a530, 0x4, 0xc000036280, 0xc00000e228, 0x1, 0x1, 0xc00007b360, 0x1, 0x0, ...)
        /home/aurelien/dev/go/src/go/types/api.go:387 +0x188
go/go2go.rewriteFilesInPath(0xc0000703c0, 0x0, 0x0, 0xc0000166a0, 0x17, 0xc000066490, 0x1, 0x1, 0x0, 0x0, ...)
        /home/aurelien/dev/go/src/go/go2go/go2go.go:93 +0x4dd
go/go2go.rewriteToPkgs(0xc0000703c0, 0x0, 0x0, 0xc0000166a0, 0x17, 0xc0000101a0, 0xc0000166a0, 0x17, 0x7ffca31cc840, 0x9)
        /home/aurelien/dev/go/src/go/go2go/go2go.go:46 +0x165
go/go2go.Rewrite(...)
        /home/aurelien/dev/go/src/go/go2go/go2go.go:30
main.translate(0xc0000703c0, 0xc0000166a0, 0x17)
        /home/aurelien/dev/go/src/cmd/go2go/translate.go:15 +0x47
main.main()
        /home/aurelien/dev/go/src/cmd/go2go/main.go:54 +0xb25

What did you expect to see?

Not sure about the type inference rule here, but I was either expecting a message telling me that the type of NewCache can't be inferred or a successful compilation.

What did you see instead?

go2go panicked.

Note I think the code is straightforward but I can always try to provide a smaller reproducer

closed time in 3 months

arl
more