Adapt gendeclarations.lua/msgpack-gen.lua to allow the `ArrayOf(...)` and
`DictionaryOf(...)` types in function headers. These are simple macros that
expand to Array and Dictionary respectively, but the information is kept in the
metadata object, which is useful for building clients in statically typed
languages.
Instead of building all metadata from msgpack-gen.lua, we now merge the
generated part with manual information(such as types and features). The metadata
is accessible through the api method `vim_get_api_info`.
This was done to simplify the generator while also increasing flexibility(by
being able to add more metadata)
Enhance msgpack-gen.lua to extract custom api type codes from the ObjectType
enum in api/private/defs.h. The type information is made available from the api
metadata and clients can use to correctly serialize/deserialize these types
using msgpack EXT type.
Specialized array types(BufferArray, WindowArray, etc) were added to the API for
two main reasons:
- msgpack used to lack a way of serializing appliaction-specific types and there
was no obvious way of making an API function accept/return arrays of custom
objects such as buffers(which are represented as integers, so clients didn't
have a way to distinguish from normal numbers)
- Let clients in statically-typed languages that support generics have a better
typed API
With msgpack 2.0 EXT type the first item is no longer a factor and this commit
starts by removing the specialized array types. The second item will be
addressed in the future by making the API metadata return extra useful
information for statically-typed languages.
This is how API dispatching worked before this commit:
- The generated `msgpack_rpc_dispatch` function receives a the `msgpack_packer`
argument.
- The response is incrementally built while validating/calling the API.
- Return values/errors are also packed into the `msgpack_packer` while the
final response is being calculated.
Now the `msgpack_packer` argument is no longer provided, and the
`msgpack_rpc_dispatch` function returns `Object`/`Error` values to
`msgpack_rpc_call`, which will use those values to build the response in a
single pass.
This was done because the new `channel_send_call` function created the
possibility of having recursive API invocations, and this wasn't possible when
sharing a single `msgpack_sbuffer` across call frames(it was shared implicitly
through the `msgpack_packer` instance).
Since we only start to build the response when the necessary information has
been computed, it's now safe to share a single `msgpack_sbuffer` instance
across all channels and API invocations.
Some other changes also had to be performed:
- Handling of the metadata discover was moved to `msgpack_rpc_call`
- Expose more types as subtypes of `Object`, this was required to forward the
return value from `msgpack_rpc_dispatch` to `msgpack_rpc_call`
- Added more helper macros for casting API types to `Object`
any
When receiving strings *from* msgpack, we don't need to duplicate/free since
the data only lives in the msgpack parse buffer until the end of the call.
But in order to reuse `msgpack_rpc_free_object` when sending event data(which is
sent *to* msgpack), Strings must be freed, which means they must also be
allocated separately.
- Define specialized arrays for each remote object type
- Implement msgpack_rpc functions for dealing with the new types
- Refactor all functions dealing with buffers, windows and tabpages to
return/accept handles instead of list indexes.
