fix(gnovm): check const type and values expr

[MikaelVallenet]

closes #2628

this code should not work following the issue above since the type is not valid for const

package main

func main() {
	const b []string = []string{}
	println("Hello", b)
}

The proposal avoid any expression that is not a basic litteral or a name expr fixing the issue above.

Ideally, we'd need to check that NameExpr have good underlying type & value to fix the underlying code

package main

func main() {
	var x = 10
	const y = -x
}

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 60.15%. Comparing base (14b9015) to head (b45887d).
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2651   +/-   ##
=======================================
  Coverage   60.15%   60.15%           
=======================================
  Files         560      560           
  Lines       74738    74738           
=======================================
+ Hits        44955    44958    +3     
+ Misses      26397    26394    -3     
  Partials     3386     3386           

Flag	Coverage Δ
contribs/gnofaucet	15.31% <ø> (+0.85%)	⬆️
misc/genstd	80.54% <ø> (ø)
misc/logos	19.88% <ø> (ø)
tm2	62.03% <ø> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ltzmaxwell]

thank you for your work! can you add a test for the fix?

[ltzmaxwell]

see this case:

package main

type f func()

func foo() {
	println("foo")
}

const ff = foo

func main() {
	println("ok")
}

it should be excluded, right?

[MikaelVallenet]

Thanks for comment, In fact, I'm having a bit of trouble figuring out how to check that a name expr is a const or a cast of a basic type, for example const x = uint(8), do you have any tips to give me on this? In the meantime, I'll keep working on the code and keep looking, thanks.

[ltzmaxwell]

It seems there may be a misunderstanding about the use of nameExpr as the right-hand side (RHS) of a const declaration. For example:

const a = 1
// 'a' qualifies as a ConstExpr
const b = a

In this case, using a as the RHS in the declaration of b is perfectly valid since a is evaluated to be a constant expression.

Regarding the expression uint(8), this is a CallExpr with the function type(TypeType) of uint8. I'm not certain if this directly addresses your question.

However, I recommend we ensure a shared understanding of the related concepts by reviewing the section on constants in the Go language specification: Go Constants.

Tips, you can try to conduct checkValConstValue in trans_leave *ValueDecl to see if it works.

[ltzmaxwell]

also this one:

package main


var x = 1

const ff = 1 << x

func main() {
	println("ok")
}

[MikaelVallenet]

Hello @ltzmaxwell,

I understand better thank you, however not all RHS are constExpr by default and this code is then executed to transform them at the last moment.

if n.Const {
	// NOTE: may or may not be a *ConstExpr,
	// but if not, make one now.
	for i, vx := range n.Values {
		n.Values[i] = evalConst(store, last, vx)
	}
}

So i tried to just change this code by adding a if !isConst(vx) -> panic but some expr are not yet evaluted as const.

I'm wondering whether I should try to evaluate all constant expressions as constExpr before reaching the snippet of code above or continue along the path of checking each type of expression, which can be complicated by the fact that special cases exist in many cases?

I also noticed that this code evaluates the const Minute as a constExpr.

package main

import (
	"fmt"
)

type Duration int64

const (
	Nanosecond  Duration = 1
	Microsecond          = 1000 * Nanosecond
	Millisecond          = 1000 * Microsecond
	Second               = 1000 * Millisecond
	Minute               = 60 * Second
	Hour                 = 60 * Minute
)

const df = Minute

func main() {
	fmt.Printf("df: %v %T\n", df, df)
}

but this code where i import the pkg time does not evalue the RHS time.Duration of the const decl. as a constExpr before the final loop, which transforms the RHS into constExpr regardless of its value.

package main

import (
	"fmt"
	"time"
)

const df = time.Minute

func main() {
	fmt.Printf("df: %v %T\n", df, df)
}

It's one of my problems right now.
I closed the PR for now since i think i need more vision and knowledge about the whole architecture to fix the problem, i would be happy to peer-code the fix or see a proposal for this issue.

[ltzmaxwell]

It seems there may be a misunderstanding about the use of nameExpr as the right-hand side (RHS) of a const declaration. For example:

const a = 1
// 'a' qualifies as a ConstExpr
const b = a

In this case, using a as the RHS in the declaration of b is perfectly valid since a is evaluated to be a constant expression.

Regarding the expression uint(8), this is a CallExpr with the function type(TypeType) of uint8. I'm not certain if this directly addresses your question.

However, I recommend we ensure a shared understanding of the related concepts by reviewing the section on constants in the Go language specification: Go Constants.

Tips, you can try to conduct checkValConstValue in trans_leave *ValueDecl to see if it works.

[MikaelVallenet]

Hello,

To keep up to date with progress, I'm experiencing difficulties managing all cases, since some constant expressions, such as the import of a constant are not evaluated as ConstExpr. This is also the case for the len/cap function on a const and many other expr...

I've tried to add constExpr evaluation to the expressions that were missing, but I'm running into several problems.

I'm going to work sideways on the issue, and if anyone who's interested in the issue decides to work on it, I'll be happy to share my exp on it in more detail. 👍