fix: addressability problem

[petar-dambovaliev]

Fixes issue
Alligns the behavior with the Go spec.

[codecov]

Codecov Report

Attention: Patch coverage is 68.18182% with 28 lines in your changes missing coverage. Please review.

Project coverage is 60.23%. Comparing base (aae5d49) to head (c26c7c3).

Files	Patch %	Lines
gnovm/pkg/gnolang/values.go	58.46%	23 Missing and 4 partials ⚠️
gnovm/pkg/gnolang/gonative.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2689   +/-   ##
=======================================
  Coverage   60.23%   60.23%           
=======================================
  Files         562      562           
  Lines       75091    75170   +79     
=======================================
+ Hits        45228    45281   +53     
- Misses      26482    26503   +21     
- Partials     3381     3386    +5     

Flag	Coverage Δ
contribs/gnodev	61.40% <ø> (ø)
contribs/gnofaucet	14.46% <ø> (ø)
misc/genstd	80.54% <ø> (ø)
misc/logos	20.23% <ø> (ø)
tm2	61.94% <ø> (-0.14%)	⬇️

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.

[deelawn]

It looks like it is close to completion but there a few more cases that need to be covered.

Also, is this something that we could do in the preprocessor? Like adding an attribute to expressions that are not currently addressable?

[deelawn]

Here is another case where execution should not succeed:

package main

func main() {
	var s S
	assert4(s)
}

type S struct {
	s string
}

// Should fail but does not
func assert4(i interface{}) {
	_ = &((i.(S)).s)
}

In this case the type assertion of the struct makes a copy of the value, so it is not addressable and should not be able to get the address of S.s.

[deelawn]

Closing in favor of #2731