Now you can't use the same syntax as you would for a method to
implement a property as whole, instead you need to specify the
getter and/or setter explicitly. This is to allow parent classes
to expand their properties without altering behavior of the child
classes.
The system now verifies whether the class of an implement or
constructor exists within the inheritance hierarchy. It also
properly checks duplicates everywhere and prints better error
messages.
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.
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
Summary:
Currently eolian abbreviates when only the last word of class name and
the first word of method name are same, but this patch abbreviates
generated c name of function to remove all duplicated affix.
For example, "efl_io_closer_fd_closer_fd_set" will be "efl_io_closer_fd_set".
Reviewers: jpeg
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4430
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
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
This implements a new builtin, stringshare, which is replaced with the right
pointer to Eina_Strinshare as necessary. This allows simplifying binding code
(it can call the proper eina APIs, deal with lifetime etc).
It also removes the extern Eina.Stringshare typedef from eina_types.eot, which
was actually incorrect and would generate invalid code in binding generators.
@feature @fix
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
Because of this the cyclic check would occasionally have false positives.
By moving deferred eo parsing to the end of the whole parse process, it
can no longer affect the cyclic checker.
@fix
Previously, multi-char tokens (such as strings, docs etc) always put the error
cursor to the end of the token. That was confusing, so now the cursor always
appears at the beginning of the token instead (for multiline tokens, currently
only docs, the line number is also adjusted to point to the first line of the
doc token).
@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
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
This adds env var EOLIAN_PROPERTY_DOC_WARN which enables extra
warnings for properties that don't have a general doc but have
getter/setter doc. This will eventually become an error and
will be enabled by default. For now it's too verbose.
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
Add a promise object to allows Eolian interface to include promises
as a way to have asynchronous value return and composibility.
The usage is like this in a .eo file:
class Foo {
methods {
bar {
params {
@inout promise: Promise<int>;
}
}
}
}
Which will create the following API interface:
void foo_bar(Eo* obj, Eina_Promise** promise);
and a Eina_Promise_Owner for the implementation, like this:
void _foo_bar(Eo* obj, Private_Data* pdata, Eina_Promise_Owner* promise);
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Reverting this at Felipe's request following my email. There are many
things I strongly object to in this commit. I've touched the surface of
those on the ML (which doesn't work at the moment), though we need to
better discuss it.
The gist:
1. dlsym is a really bad hack that is not even needed.
2. I don't see why eo should even be aware of promises. It's not aware
of list, hash and etc.
3. The eolian changes were done wrong.
This should have been discussed and consulted before done, even if only
because of the amount of hacks it includes and the cross-domain (ecore,
eo and eolian) nature of it.
This reverts commit f9ba80ab33.
Add a promise object that allows Eolian interface to include promises
as a way to have asynchronous value return and composibility.
The usage is like this in a .eo file:
class Foo {
methods {
bar {
params {
promise: Promise<int>;
}
}
}
}
Which will create the following API interface:
void foo_bar(Ecore_Promise** promise);
and the equivalent declaration for implementation.
However, the API function will instantiate the Promise for the
user and the implementer of the class.
This allows generators to silence type errors in validation in order
to reduce duplicate error messages when generating multiple files.
Also adjusted the C generator to only emit type errors when generating
Eo header files.
@feature
We have to use void in a function declaration if we want no function
parameters. Using just empty parenthesis means the function takes an
unspecified number of parameters.
We had it correct for most declarations and this series fixes it for
the rest.
This changes the checks in eolian type API so that you can use the various
type funcs on incompatible types, getting a NULL in return; this allows
simplified generator logic, with error handling done on generator side,
without getting annoying messages from the Eolian lib.
This doesn't quite work yet as path sanitization needs to be done for it to
work correctly. For now this code path is disabled and will be enabled once
all paths are correctly sanitized.
Replacing decimal point in buffer resulted in invalidation of the original
string pointer. On Linux, this issue was for some reason not caught, but
it was wrong anyway. Use the updated string correctly now.
@fix
It's now generalized to work properly with legacy functions
as well as correctly append suffixes. Thus, it can be easily
used with the documentation generator and in other places.
@feature
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 fixes parsing of floating point number with locales that use
a comma as decimal separator, as strtof/strtod follows locale
specific conventions.
@fix
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 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
Eo files will now fail to compile if a cycle is detected.
This required some temporary changes in existing eo files
(we had 2 cycles) for which I added a FIXME (they do not
affect C generation).
@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
Instead of "@in type name;" we now use "@in name: type;". This change
is done because of consistency with the rest of Eolian; pretty much
every other part of Eolian syntax uses the latter form.
This is a big breaking change in the .eo format, so please update your
.eo files accordingly and compile Elementary together with the EFL.
@feature
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
If the class is not found, we retrieve its full path if it has already
been scanned.
This patch is needed by Espion so Eolian can find the full path of a
class by its name. Espion has no way to determine it by itself.
Also disable typed expression validation for now. The interfaces are not
finished yet so some things will fail validation because of unexistent
type definitions.
Fixes T2064.
@fix
This patch adds a list of strings called 'ctor_of' to
_Eolian_Function. This list will contain all classes in which this
function is a constructing function.
ctor_of is filled in two moments:
* When filling the constructors of a class, class->full_name is inserted
in the 'ctor_of' of each constructor's function.
* When filling the implements of a class, if the function is a
constructor of its superclass it also becomes a constructor of the
current class, so class->full_name is also inserted in the 'ctor_of'
of each implement's function.
eolian_function_is_constructor gets a func and klass arguments. It goes
through ctor_of of func and returns EINA_TRUE if klass->full_name is
found, otherwise it returns EINA_FALSE.
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.
Now they're registered correctly. Also, add new API, eolian_implement_is_virtual.
Also, deal with get/set properly (when filling in additional implements)
As the implements list will soon contain all methods and properties,
do some preparations. The Eolian library now fills in class field in
implements early on when the implement is local. The Eolian C generator
now checks for local implements and skips them (so that things don't break).
This adds a few new APIs to retrieve the type of an expression, operators
for binary and unary expressions, lhs/rhs for binary expressions, expr for
unary expressions and value for other expressions.
Because of Eina_Value being less than optimal in our usage, we're dropping it in Eolian.
This simplifies the code and makes it easier to bind to other languages, which
will aid new generators. Also, we're dropping long double support from eo files
and expressions as it causes an ABI breakage in gcc 4.4.
This change adds a new API to retrieve the legacy prefix for enum members
and also adds support for generating enums into the C generator. Besides that,
it prevents generation of entire struct contents when the .eo file declares
a named struct inside of a typedef - as the struct itself gets generated later on.
I don't know what I was thinking, struct and enum fields need to be ordered
so now we keep a separate list around containing the field names in correct order.
This implements the previously declared APIs to manipulate enum types. Also,
it implements the appropriate lookups in expression evaluation so that you
can refer to constants and enums inside constant expressions.
Also added API to retrieve value of a variable (forgot about that one)
and made it impossible to create extern constants (doesn't make sense)
as well as made it impossible to give extern globals values.
Daniel Kolesa
Cedric BAIL
Jee-Yong Um
Tom Hacohen
Gustavo Sverzut Barbieri
Felipe Magno de Almeida
Stefan Schmidt
Daniel Zaoui
Jean-Philippe Andre
Daniel Zaoui
Daniel Kolesa
Mike Blumenkrantz
Stefan Schmidt
Kai Huuhko
Savio Sena
Carsten Haitzler
Jérémy Zurcher