This is the new ownership system for Eolian, working on params,
returns, struct fields or events directly rather than specifying
ownership at type level. As the new system will evolve it will
gain missing features and necessary checks.
Summary:
Summary : String buffer returned by eina_strbuf_new() is not freed in some cases
@Fix
Signed-off-by: Uma Devika <u.bodapati@samsung.com>
Reviewers: cedric, tasn, jpeg, raster, singh.amitesh
Subscribers: tanwar.umesh07, yashu21985, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5000
First steps toward explicit function pointer support in eolian.
To declare a function pointer type, use the following syntax, similar to
a regular eolian method declaration.
function FunctionName {
params {
...
}
return: Return type
}
This allows us to unify retrieval of docs for both regular and
overridden funcs without having two separate APIs. It's currently
missing validation and docgen is still not adjusted properly for
it either, but at least there's this. Enables retrieval of docs
for overridden funcs by default as well.
As there is no need to have separate is_auto, is_empty and
is_pure_virtual for functions and implements (each function has
its own base implement by default) I removed the function ones.
Instead, I added a way to retrieve a function's base implement
so that you can instead do the checks on the implement even when
you only have the function.
I also moved base implement build directly into the parser instead
of the database filler. That allows for significant cleanup. I
also removed distinction of implement pointers in Eolian_Function
for get and set as implements now always contain an entire thing
so the pointer was always the same anyway.
Things should still behave more or less the same, but ordering
of generated functions has changed because ordering of implements
has changed.
Previously one API used just virtual (incorrect) and one used
virtual_pure (which just sounds weird). So unify with a single
name, pure_virtual, similar as in other lanugages.
This does not change eo file syntax yet.
Now all error/unknown/etc values returned from APIs are zero,
previously it was a mix of zeroes and minus ones. Also, some
enums that had no error/invalid value before have one now, which
allows for better distinction between what is an error and what
is an intended result.
Instead of
Other.Class.some_prop.get;
Other.Class.some_prop.set;
you can write
Other.Class.some_prop { get; set; }
The other syntax is deprecated from now on.
Both variables and constants can have extern on them (it means the same thing
as in types, they won't get generated in C). This is different from the previous
semantics which only allowed extern on globals, which makes no sense.
Both globals and constants are allowed to have a value (previously only
constants were); constants are required to have a value. Globals having
a value is just a convenience for initialization during source generation.
This is unlike the previous behavior, where the value was optional for both
globals and constants and only allowed when not marked extern, which makes
no sense either.
Obivously, even when globals have a value, they're not allowed to be used
in expressions, as they cannot be evaluated at compile time (they're mutable).
Future is the read only side of a Promise. For now, I am not removing
Eina_Promise until everything is in place, but eventually the promise
type of eolian will be gone.
Adds two new type types, STATIC_ARRAY and TERMINATED_ARRAY. Static arrays are
only allowed as struct members right now - they translate to regular C static
arrays (allowing them elsewhere wouldn't be good, as C isn't very good at
working with the size information). Terminated arrays are basically sequences
of data terminated at the end. The base type of static arrays can be any type
that is not marked ref (explicit ref may get allowed later). The base type of
terminated arrays has the same restriction plus that it has to be either
implicitly reference type (i.e. translating to pointer in C), integer type
or a character. In case of ref types, the terminator is NULL. In case of
integer types, the terminator is a zero. In case of character types, the
terminator is also a zero (null terminator like C strings).
@feature
Somehow, there was code in the tree that apparently isn't tested at all, even
once - if it was, the eo.c logic that performs inheritance checks would be
triggered. I don't know how this could have happened (actually I do, it's
Cedric's fault and he should be publicly shamed for it) but these checks
make sure this will never happen again. But since the code itself appears
to be untested, I don't know if there isn't any other brokenness in it.
But that's beyond the scope of this change, so for now, let's make sure
all our inheritance is at least formally correct.
Also, enable eo_interface.eo generated code in Eo itself so that Eo.Interface
can be used when inheriting.
@fix
Inner type can now be retrieved as a base type of the type.
If the type has two inner types or more, there is a new API that allows you to
get the second inner type by calling it on the first one (same would apply to
getting third via second etc.).
This API is simpler to use and doesn't require an iterator.
It's now possible to mark struct fields and function params as "references",
which causes them to become pointers in C (in bindings, they become whatever
is necessary). They're not a part of the type and are much more restricted
than pointers, allowing bindings to be easier. This system will be gradually
utilized and expanded as required.
@feature
Daniel Kolesa
Uma Devika
Lauro Moura
Cedric BAIL
Gustavo Sverzut Barbieri