In this case emitted event parameters should match from invocation to
invocation. It's an error otherwise (and if the type is not Any).
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
There are two ways of doing this: first one is to emit all notifications
parameter data into rpcbindings configuration on compile time (event if
the parameter has a simple type), and the second one is to fetch parameter
type from the manifest on rpcbinding file generation if needed (we always
have manifest at this stage, thus it's not a problem to retrieve necessary
information). The latter case is chosen to reduce the bindings configuration
file size.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Notification and its parameters may have any UTF8-compatible name
which is inappropriate for bindings configuration and for the resulting
RPC bindings file. This commit stores the prettified version of
notification's name and parameters that are ready to be used in the
resulting RPC binding without any changes.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
The user should specify it via parameter's `extendedtype` field and
via upper-level `namedtypes` field of the contract configuration YAML.
Also, as we have proper event structure source, make the `--guess-eventtype`
compilation option and make event types guess optional.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Everywhere including examples, external interop APIs, bindings generators
code and in other valuable places. A couple of `interface{}` usages are
intentionally left in the CHANGELOG.md, documentation and tests.
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.
For some reason `foo.go` is interpreted as an http URL, and even if we
replace it with `./foo.go` there is an errors with file missing on disk.
Because `CompileWithOptions` should be able to compile file under any
circumstances, we allocate temporary directory base on version used to
compile a binary.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
It is a simple wrapper over `CompileWithOptions` which we don't really
need. Custom options can be specified explicitly instead of using some
random default. This default was introduced in 1578904da, however tests
written there use `CompileWithOptions` and all other tests
pass on that commit even without this default.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
If a method is missing from the manifest, it is most likely a typo
or regression after refactoring. There is no "turn-off" flag
for this error because we can do this precisely.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
We're only using queue library and it didn't change in any way, but 1.0.53 has
proper go.mod, so it's still an improvement.
It at the same time pulls some new packages also like x/tools.
If a method is known at compile time we can still check
if it is present in the list of methods of at least one contract.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
On many occassions we can determine at compile-time if contract config lacks
some properties it needs. This includes all native contract invocations
through stdlib, as both hashes and methods are known at compile-time
there.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
For proper NEO3 debugger work we should provide namespaces for events
names in .debug.json files. But we don't have namespaces in .yml
configuration files and don't need this information for .manifest.json
generation, so let's just keep namespaces empty. This do not prevents
debugger from accepting our .debug.json files.
We currently can't process events in codegen, so we have to provide
them via .yml config file. Do not delete the rest of the code connected
with conversion of MethodDebugInfo.Event into manifest.Event as we have
issue #1038.
It's not needed any more with Go 1.13 as we have wrapping/unwrapping in base
packages. All errors.Wrap calls are replaced with fmt.Errorf, some strings are
improved along the way.
