This patch modifies the code generator to only generate C-language
`#include <imported_schema.h>` lines for imports that are actually used.
Imagine this transitive import scenario: schema A imports a definition
from schema B. However, the definition imported from schema B was
itself imported from schema C.
In this case, the code generated for schema A need not include the
header file for schema B, as it only needs definitions from schema C.
Signed-off-by: Curt Brune <curt@enfabrica.net>
schema files.
Some schema files (eg. those that only decalare annotations) do not actually
result in any generated C code. They do not need to have a corresponding
include directive for C files generated from schemas that include them. This
introduces a "donotinclude" annotation that takes the Cap'n Proto ID (a
UInt64) of any such files and skips generating the include directive for them.
ANSI C makes no guarantee about the size of an enum, only that it will be the
minimum required integer type that can hold all the given values. Treating
enums as interchangeable with uint16_t data caused undefined behavoiur on
platforms where enums were always at least 32 bits.
With some toolchains, compilation of str.c produced the following error:
compiler/str.h:56:50: error: unknown type name ‘va_list’
int str_vaddf(struct str *v, const char *format, va_list ap) ATTR(2,0);
^~~~~~~
One toolchain had the following in its stdarg.h:
"We deliberately do not define va_list when called from
stdio.h, because ANSI C says that stdio.h is not supposed to
define va_list."
str.c includes stdio.h, but none of the prior includes result in the
inclusion of stdarg.h. Therefore, explicitly include it in str.h to fix
the issue on toolchains following this ANSI C rule.
Signed-off-by: Joel Carlson <JoelsonCarl@gmail.com>
When the c-capnp compiler runs, currently only takes the len of 1st
segment in the list as a capacity used in the generator for constants
definitions.
This works when the schema processing only generates 1 segment, or the
1st segment has 8192 bytes. There are cases where the fd returns
multiple segments an the first one has very low capacity (e.g. 96 or 80).
Hence, if more constants require to be allocated for the current schema
it will have misleading positions.
This commit takes a conservative approach by summing up all the lenghts
of capnproto segments obtained at the fd_init call of the compiler.
Those values are taken to set the memory allocation and the max
capacity for the segment utilized in the code generation.
(Marker merge -- cherry-picked the size format; the align one is
superseded and the gtest ones collide with gtest's upstream
recommendations [only Gentoo has gtest as a package].)
The case of creating capnp lists of size 0 didn't consider lists of
composite elements (structs), which requires the addition of list
element information.
This commit removes the case of size 0 when creating the list in order
to enable the creation of 0 sized lists of any element type (struct).
