nickng / gospal Goto Github PK

_unexported_ channels sometimes appear in inferred types by migoinfer. This should not happen.

The MiGo types extracted for this program twobuyers.go have an issue. For the buyer1 goroutine migoinfer gets the order and type of operations right, but the operations are presented as happening on the same channel, when in the program they happen on different channels.

These are the generated MiGo types: twobuyers.cgo
As can be seen on lines 25, 26 and 27 the operations are erroneously presented as happening on the same channel.

The following program will generate unparsable MiGo types because of importing the net package.
Moreover, the generated os.NewFile# functions degenerate to an empty channel operation (tau).

package main
import (
  "fmt"
  "time"
  "net"
)

func Send(ch chan<- int) {
	ch <- 42
}

func Recv(ch <- chan int, done chan<- int) {
	val:= <-ch
	done<-val
}


func Work() {
	for {
		fmt.Println("Working...")
		time.Sleep(1*time.Second)
	}
}


func main() {
	ch, done := make(chan int), make(chan int)
	
	
	conn, err := net.Dial("tcp", "localhost:5678")
	if err != nil {
		fmt.Println(err)
	}
	_ = conn // this is to prevent unused variable error
	
	go Send(ch)
	go Recv(ch,done)
	go Recv(ch,done)
	go Work()
	
	<-done
	<-done
	
}

Inferer cannot be used concurrently. It may lead to runtime crash concurrent map read/write for constant storage and others.

Potential source: callctx.Toplevel() uses a shared storage.

In the program examplewithstruct.go the channels are encapsulated in a struct which is passed as a pointer to the two goroutines. endChannel is used to signal to main that a goroutine is exiting and is not part of the struct.

examplewithstruct.cgo contains the MiGo types extracted by migoinfer for examplewithstruct.go.
I bring your attention to lines 11 and 12. In line 11, endChannel appears as the first argument in the function call, while in line 12 it appears as the last parameter.