The logic to manage generating typescript in a single file was
generating self imports and unused local names, which triggered some
linters.
This resolves#7191
There was a step in the compilation process where benchmark data is
downloaded before starting the kotlin compilation process.
Since we are not running benchmark on CI anymore, we remove the
dependency. To run benchmarks the download task needs to be executed
manually.
* Implement optional scalars for JSON
* Add optional scalars JSON test
* Extend JSON optional scalars test to test without defaults
* Fix optional scalars in JSON for binary schema
Co-authored-by: Caleb Zulawski <caleb.zulawski@caci.com>
Right now, reflection_ts_fbs target is in reflection/BUILD.bazel.
This is not ideal because reflection:reflection_fbs_schema is referenced
from :flatc in the root. Thus, for any Bazel projects that want to
include flatbuffers, they need to include npm / yarn_install and nodejs
support all because reflection/BUILD.bazel loads typescript.bzl and that
requires all TypeScript things.
This PR separated that target into a different subdirectory, freeing
root BUILD.bazel from that dependency.
* Implement optional scalars for Python
* Use == for integer comparison, remove empty line
* Fix optional type hint
Co-authored-by: Caleb Zulawski <caleb.zulawski@caci.com>
Fixes#7320.
I realize that Rust doesn't really follow the Namer convention, since
it uses Field case for methods... that's a future problem.
Co-authored-by: Casper Neo <cneo@google.com>
* Add explicit return types to lobster generated code
* Add support for optional fields.
Convert to bool explicitly from int8 to match type signature
Fix whitespace
I think these changes reflect the current state, but I found it hard to
track the state of some of the planned work. Hence why it'd be good to
have it documented :)
I also expanded some sections that I found misleading, as somebody
familiar with Rust and FlatBuffers separately. Parts of these pages seem
to be aimed at people familiar with FlatBuffers (ie via the other
documentation pages) but not each language, which I'm trying to
preserve. However, Rust does some things differently, and as somebody
with expectations about how typical Rust APIs work the discussion of
threading made me wonder what was different.
std::span lacks these; make the flatbuffers STL emulation and tests
match. This fixes a compile error in C++20 mode when using std::span.
Bug: chromium:1284275
* Set an explicit 2018 edition for Rust tests
* Replace all `std` usage with `core` and `alloc` in Rust code generator
* Update the generated files
* Make Rust tests actually use no_std when the corresponding feature is enabled
* Keep the underlying storage capacity when clearing the FlatBufferBuilder. Gives a significant performance boost for serialisation of many small messages.
* Use Googles Swift benchmark library for more consistent results and dynamic number of iterations, simplification of tests as result.
Co-authored-by: Joakim Hassila <hassila@users.noreply.github.com>
Since CreateVectorOfStrings() takes a templated container, make sure that
the default template deduction from just an initializer list will
still work.
Signed-off-by: Henner Zeller <hzeller@google.com>
* [Java] Fix key lookup returning null clashing with default value
A field with key attribute must always be written on the message so it
can be looked up by key. There is a edge case where inserting a key
field with same value as default would prevent it to be written on
the message and later cannot be found when searched by key.
* [Kotlin] Fix key lookup returning null clashing with default value
A field with key attribute must always be written on the message so it
can be looked up by key. There is a edge case where inserting a key
field with same value as default would prevent it to be written on
the message and later cannot be found when searched by key.
Co-authored-by: Derek Bailey <derekbailey@google.com>
A field with key attribute must always be written on the message so it
can be looked up by key. There is a edge case where inserting a key
field with same value as default would prevent it to be written on
the message and later cannot be found when searched by key.
Any string type that is supported by CreateString(), e.g.
const char* or string_view will now also work.
Signed-off-by: Henner Zeller <hzeller@google.com>
