In case of ellipsis usage compiler defines argument type as ArrayT
(which is correct, because it's a natural representation of the last
argument, it represents the array of interface{}).
Here goes the problem:
```
=== RUN TestEventWarnings/variadic_event_args_via_ellipsis
compiler_test.go:251:
Error Trace: compiler_test.go:251
Error: Received unexpected error:
event 'Event' should have 'Integer' as type of 1 parameter, got: Array
Test: TestEventWarnings/variadic_event_args_via_ellipsis
```
Parsing the last argument in this case is a separate complicated problem
due to the fact that we need to grab types of elements of []interface{} inside the
fully qualified ast node which may looks like:
```
runtime.Notify("Event", (append([]interface{}{1, 2}, (([]interface{}{someVar, 4}))...))...)
```
Temporary solution is to exclude such notifications from analysis until we're
able to properly resolve element types of []interface{}.
It's possible that declared manifest event has parameter of AnyT for
those cases when parameter type differs from method to method. If so,
then we don't need to enforce type check after compilation.
Otherwise the following error occurs while updating dependency:
```
github.com/nspcc-dev/neo-go/examples/nft-nd-nns tested by
github.com/nspcc-dev/neo-go/examples/nft-nd-nns.test imports
github.com/nspcc-dev/neo-go/pkg/compiler imports
gopkg.in/yaml.v3 tested by
gopkg.in/yaml.v3.test imports
gopkg.in/check.v1 imports
github.com/kr/pretty loaded from github.com/kr/pretty@v0.1.0,
but go 1.16 would select v0.3.0
github.com/nspcc-dev/neo-go/examples/nft-nd-nns tested by
github.com/nspcc-dev/neo-go/examples/nft-nd-nns.test imports
github.com/nspcc-dev/neo-go/pkg/compiler imports
gopkg.in/yaml.v3 tested by
gopkg.in/yaml.v3.test imports
gopkg.in/check.v1 imports
github.com/kr/pretty imports
github.com/kr/text loaded from github.com/kr/text@v0.1.0,
but go 1.16 would select v0.2.0
To upgrade to the versions selected by go 1.16:
go mod tidy -go=1.16 && go mod tidy -go=1.17
If reproducibility with go 1.16 is not needed:
go mod tidy -compat=1.17
For other options, see:
https://golang.org/doc/modules/pruning
```
We've declared that we are using semantic versioning. We also want to use `git
describe` to make version strings for us because it's very convenient for
development builds (tagged versions are way simpler). The problem is that the
default `git describe` behavior is not semver compliant. If the most recent
tag is v0.99.2 then it'll generate something like '0.99.2-131-g8dc5b385',
which according to semver is a development version _before_ 0.99.2. While it's
obviously a version _after_ 0.99.2.
That's the one and only reason we have vX.Y.Z-pre tags in our repo. We set
them right after the release according to the release process and that gives
us some '0.99.3-pre-131-g8dc5b385' versions we're all used to. But these tags
are ugly as hell and they clutter up our repo over time.
So there is this idea that we can do patch version increment dynamically.
Making '0.99.2-131-g8dc5b385' be '0.99.3-pre-131-g8dc5b385' without any *-pre
tags. This patch implements this. It's ugly as hell as well, but at least
that's an ugliness somewhere inside our Makefile and not directly visible in
our tags. If we're to do this we can then greatly simplify our release process
(and even allow for CHANGELOG patches to be merged normally).
I know this can be done with awk in somewhat easier way, but no, I'm not into
awk, sorry.
