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>
Currently we have problems with unnamed structs used as a parameter for
notifications, because there's no one-to-one correspondence between
notification parameter and the list of extended types used by the whole
contract. Otherwise eventtypes guessing works OK.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
config_extended.yml contains an example of user-defined configuration
file with extended event types. User-defined event types are allowed
to be named and complicated, i.e. properly support extended types
notation.
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>
New rule for writing blocks of code to our template: new line before
the block starts and new line after the block ends. This rule is the
same as the one we use during manual typing.
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.
* strip NEP-XX methods before going into generator to avoid unused imports
* nepXX.Invoker types already include Call
* always import util, it's used for Hash
