lisa-analyzer/go-lisa

Golang frontend for LiSA

go-lisa's Issues

Failing testInteprocedural5

On branch master (commit 5bec887), in InterproceduralTest, the interproc5 test is failing due to a problem on the toString method of GoKeyedLiteral.

Supporting Go type assertions

A type assertion in Go provides access to an interface value's underlying concrete value. Consider the example taken from the Go Tour

t := i.(T)

This statement asserts that the interface value i holds the concrete type T and assigns the underlying T value to the variable t. If i does not hold a T, the statement will trigger a panic.

Go labeled statement

Go allows defining labeled statements, that are not currently supported by the Go front-end.

Supporting Go anonymous functions

Currently, GoLiSA does not support anonymous functions (https://golang.org/ref/spec#Function_literals). We should be able to both support its parsing and its semantics.

Supporting Go channels

Currently, GoLiSA does not support/parse the Go channel statement (https://tour.golang.org/concurrency/2)

Scoped variables in anonymous functions

In commit 432526b, support for the anonymous functions has been added. Nevertheless, a bug concerning the scoped variables, when the anonymous function is invoked, is still present.
Let's consider the following function

func main() {
	a := 2
	b := func(f int) int {
			return a * f
		}(5)
}

The current scoping rules hide the variable a to the anonymous function, while it should be visible to it. Currently, when the anonymous function is invoked, any variable visible before the invocation is hidden to it.

Missing support for global variable with initialization

At 82cad83, tests testCpuUse and testCpuUseNI are ignored and do not pass due to missing support for global variable with initialization. For example, in go-lisa/go-testcases/cc/cpu-use.go:

package main

import (
	"bytes"
	"encoding/json"
	"fmt"
	"time"

	"github.com/hyperledger/fabric-chaincode-go/shim"
	pb "github.com/hyperledger/fabric-protos-go/peer"
)

//SimpleChaincode is the artifact of teh chaincode
type SimpleChaincode struct {
}

var nameSpace string = "org.cpu-use.Usage"  // global variable with initializaiton
...

Supporting multiple return values

Go has built-in support for multiple return values, for example

func f(a, b int)(int, int, int ){
    return a + b, a - q, a * q 
}
x, y, z := f(1,2)

GoLiSA should provide multiple return values and types, for example adding GoTupleType, GoTupleExpression, and GoTupleValues classes.

Supporting type switch

Currently, the type switch statement is not supported (https://tour.golang.org/methods/16). We could easily handle it treating it similarly to the standard type switch.

Missing support for Go bitwise operations

Go bitwise operations (AND, OR, XOR,...) are currently parsed by the frontend but their semantics is not implemented yet.

Refactoring GoFrontEnd

GoFrontEnd.java needs some refactoring activities. The idea of frontend is to handle at high level other components such as lexer, parser and so on. However, the logic of "visit" methods (that build CFGs) is all within this class. I suggest to create ad-hoc class to manage the visit and CFG construction phase, as already happens in IMPFrontEnd.java of LiSa where the IMP methods are visited by IMPCodeMemberVisitor.java. This allows to separate the logic of the components, uniforming the frontend structures.
Looking at the "visit" methods of GoFrontEnd, the reasoning seems to follow the same reasoning of IMPCodeMemberVisitor (except for small language differences), that is starting from the method/function declaration (a new currentCFG is assigned only in these cases) to create new CFGs by visiting the various components more and more in depth such as blocks, statements, expressions, etc.

Supporting select statement

Currently, GoLiSA does not support the select statement (https://golang.org/ref/spec#Select_statements). We should be able at least to support its parsing.

Visible identifiers in instrumented return statements

On commit 5bec887, if a Go function or method body has been parsed and does not contain any exit point (i.e., does not contain any return statement), an instrumented return is added at the end of the corresponding control-flow graph. While the generated control-flow graph is correct, the set of the visible identifiers at the instrumented return statement is always empty.

Let's consider the following function and let's suppose to analyze it with Interval and MonolithicHeap.

func main() {
	x := 1
}

The resulting dot file corresponding to the analysis results is

The analysis concerning the return node should be the same as the one for the x := 1.

Supporting goroutines

Currently, GoLiSA does not support/parse the goroutines statement (https://tour.golang.org/concurrency/1)

Supporting Go interfaces

Go provides interfaces, that are named collections of methods signatures. Currently, they are not supported by GoLiSA: the Go frontend should correctly parse them and should be able to infer which types defined in the source code program implements each declared interface (i.e., inferring the superunits of each declared type).

Supporting for range clause

Currently, GoLiSA does not support the for range iteration statement, e.g., for i, num := range nums {...}. We should create an ad-hoc cfg node for it in order to support it.

Top and bottom elements do not correctly work in relational Tarsis

Top and bottom elements do not correctly work in RelTarsis. In particular, an element of RelTarsis is top (bottom) when tarsis and rsubs are top (bottom). Instead, currently top and bottom elements of RelTarsis are treated as static elements. We should redefine top and bottom elements, together with the isTop and isBottom methods.

Blank identifier "_" should not be assigned

On branch master (commit 5bec887), the black identifier is treated as any other normal variable, and in turn, is also assigned. For instance, let's consider the following fragment and let's analyze it with the Interval and FieldSensitivePointBasedHeap abstract domains.

package main

func f() (int,int) {
		return 1,2
}

func main() {
    x, _ := f()
}

The analysis result for the mainfunction is

where also the variable _ is assigned. This should not happen. Moreover, @olivieriluca I would ask you if you can check (and write some tests about that) if the black identifier wrongly follows the same scoping logic of the other variables you have implemented. In particular, I think the anonymous variable should be never scoped, that is:

func main() {
    x, _ := f()
    _, y := f()
}

should be a legal function.