As it is no longer necessary to pass unit when evaluating exprs,
it is not necessary to pass it here either. Convert all the APIs
to the new style and update all instances in our tree.
Most of the time you need to retrieve the class from the string
anyway, so remove this relic of old Eolian and gain some small
performance benefits and extra convenience.
Subtly breaks API but everything should be updated.
These types are of questionable value and the API was not entirely
thought out - remove for now, and if a legitimate use is found
later, they may be readded (with a better API), but typically it
seems best to redesign the bad APIs around safe containers...
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
}
We don't need to keep this in eo files anymore because the APIs
using them are now fully in C. This also allows removal of the
event callback builtin from Eolian.
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.
Strictness of various Eolian APIs has been enhanced, for example
eolian_class_function_get_by_name now won't return anything if
you request an EOLIAN_PROPERTY and the found func is just an
EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs
like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will
need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD
explicitly.
The purpose of this is to reduce potential bugs and fix ambiguous
behavior. Thanks to use of EINA_SAFETY, appropriate errors should
be printed into terminal when an API is used incorrectly.
New API function eolian_doc_token_ref_get will resolve the kind of
reference in the given token and extract the necessary data you
might need for further use, for example class and function for
methods, or struct and field for struct field. It also supports
event references that will be added into Eolian later.
EFL will be switched to the new resolver (by changing the validator
code) during the next step.
This provides an API to tokenize Eolian docstrings. It does not
yet switch the rest of the infra to it, but it does have tests.
It doesn't verify correctness of references, as that's Eolian's
job. Therefore it's also your job to provide it with strings that
do not contain invalid references. Lua bindings are to come and
a complete switch will be done later.
@feature
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
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
Complex types (i.e. list, array, hash, accessor etc.) now do not require
pointers with them anymore (the pointer is implied) and the same goes for
class handles. Eolian now explicitly disallows creating pointers to these
as well. This is the first part of the work to remove pointers from Eolian
completely, with the goal of simplifying the DSL (higher level) and therefore
making it easier for bindings (as well as easier API usage).
@feature
Previously events used to use class name as a prefix and ignored eo_prefix
when specified. This is no longer the case. Events follow eo_prefix by default
now. In order to get around this for classes where this is undesirable, a new
field event_prefix was added which takes priority over eo_prefix. If neither
is specified, class name is used like previously.
@feature
Summary:
Add code to unit test to check if Eolian correctly recognize a struct
name as a struct type when it is used in a method.
Add new method to struct.eo to create this test.
Update struct_ref.c accordingly.
Reviewers: tasn, q66
Differential Revision: https://phab.enlightenment.org/D3213
Sorry for last minute new API, but this one is necessary to implement
proper verification of references in docs, which I would like to have
in 1.15. It allows you to retrieve any kind of declaration by full
namespace, so that you can check for an existence of an Eolian decl,
rather than checking every type individually.
@feature
This is kind of ugly, but I didn't see a better way to do it without turning
this into a much more complicated parser. So this will have to do unless we
find something else to add, in which case a new doc parser will be required.
@feature
This commit adds the necessary generator logic to emit doc
comments from the new doc syntax. Old doc comments are kept
in for the time being as they're used within the EFL but they
will be removed eventually. This new generator focuses all the
important code in one place, making usage easy.
@feature
This adds new APIs that deal with the new documentation syntax
provided by Eolian. The old doc comment APIs are considered
deprecated from now on and will be removed.
@feature
Sometimes it is necessary to specify a different set of values for a
getter or a setter. This commit allows such specializations. This also
renders @const_get and @const_set useless (soon to be removed).
To function correctly, this required adjustment of several public APIs
as well as deprecation of eolian_function_parameter_get_by_name.
This function was not used in any generator and was pretty much
useless in the first place, so it was removed.
@fix
This is needed in Erigo to determine if a virtual pure function can be
invoked via eo_do, as we don't want error messages to be displayed in
case of a non implementation in the Eo object.
This function works with non virtual functions too.
Tests have been provided.
@feature
From now on, there are 5 builtin complex types, particularly accessor, array,
iterator, hash and list. All other types are simple - they can't have a complex
part. Also, the <> now binds to the type itself, not the pointer. More builtin
complex types will be added as needed.
Daniel Kolesa
Marcel Hollerbach
Jean-Philippe Andre
Lauro Moura
Cedric BAIL
Vincent Torri
Vitor Sousa
Daniel Zaoui
Daniel Zaoui
Daniel Kolesa
Savio Sena