The tests are still there, coverage should counted fine, but it improves things:
? github.com/nspcc-dev/neo-go/cli [no test files]
ok github.com/nspcc-dev/neo-go/cli/app 0.058s coverage: 100.0% of statements
ok github.com/nspcc-dev/neo-go/cli/cmdargs 0.005s coverage: 60.8% of statements
ok github.com/nspcc-dev/neo-go/cli/flags 0.027s coverage: 97.7% of statements
? github.com/nspcc-dev/neo-go/cli/input [no test files]
ok github.com/nspcc-dev/neo-go/cli/nep_test 30.443s coverage: [no statements]
ok github.com/nspcc-dev/neo-go/cli/options 0.054s coverage: 50.0% of statements
? github.com/nspcc-dev/neo-go/cli/paramcontext [no test files]
ok github.com/nspcc-dev/neo-go/cli/query 2.089s coverage: 45.3% of statements
ok github.com/nspcc-dev/neo-go/cli/server 1.510s coverage: 67.8% of statements
ok github.com/nspcc-dev/neo-go/cli/smartcontract 8.433s coverage: 94.3% of statements
ok github.com/nspcc-dev/neo-go/cli/util 0.013s coverage: 10.9% of statements
? github.com/nspcc-dev/neo-go/cli/vm [no test files]
ok github.com/nspcc-dev/neo-go/cli/wallet 47.252s coverage: 63.0% of statements
Refs. #2379, but not completely solves it, one package seriously outweights
others:
? github.com/nspcc-dev/neo-go/cli [no test files]
ok github.com/nspcc-dev/neo-go/cli/app 0.036s coverage: 100.0% of statements
ok github.com/nspcc-dev/neo-go/cli/cmdargs 0.011s coverage: 60.8% of statements
ok github.com/nspcc-dev/neo-go/cli/flags 0.009s coverage: 97.7% of statements
? github.com/nspcc-dev/neo-go/cli/input [no test files]
ok github.com/nspcc-dev/neo-go/cli/options 0.033s coverage: 50.0% of statements
? github.com/nspcc-dev/neo-go/cli/paramcontext [no test files]
ok github.com/nspcc-dev/neo-go/cli/query 2.155s coverage: 45.3% of statements
ok github.com/nspcc-dev/neo-go/cli/server 1.373s coverage: 67.8% of statements
ok github.com/nspcc-dev/neo-go/cli/smartcontract 8.819s coverage: 94.3% of statements
ok github.com/nspcc-dev/neo-go/cli/util 0.006s coverage: 10.9% of statements
? github.com/nspcc-dev/neo-go/cli/vm [no test files]
ok github.com/nspcc-dev/neo-go/cli/wallet 72.103s coverage: 88.2% of statements
Still a nice thing to have.
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.
