Summary:
This enables all the checks unconditionally, without ignoring
classes that don't have an Efl namespace. This required a lot
of beta marking to make it build. It most likely doesn't
mark types correctly, as that is not fully enabled yet.
Reviewers: zmike, cedric, segfaultxavi, bu5hm4n
Reviewed By: segfaultxavi
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8266
Summary: This now does work, and we can enable the full checks
Reviewers: segfaultxavi, cedric, q66, zmike
Reviewed By: q66
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8276
Summary:
This removes all Eolian API that deals with handling of legacy
code. It also removes the code using it in the generator as well
as bindings, but for now keeps generation of .eo.legacy.h types,
as there are still instances in our codebase where things are
otherwise broken. We can remove the rest once that is resolved.
Reviewers: zmike, cedric
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8255
Summary:
This also simplifies the beta checking API by unifying it under
objects (makes much more sense that way) and reworks the validator
to have betaness support within its context state, allowing checks
to be done easily in any place.
The betaness checks are disabled for types for the time being,
because otherwise there are too many errors (types are assumed
to be stable as they are not tagged beta, but they reference beta
classes all over the place). Set EOLIAN_TYPEDECL_BETA_WARN to 1
in your environment to force enable the checks.
Reviewers: zmike, bu5hm4n, stefan_schmidt, lauromoura, cedric
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl, #eolian
Differential Revision: https://phab.enlightenment.org/D8102
This feature was kind of ill-conceived and never worked properly.
Since there isn't enough time to make it work right at this point
and there are no users of it in the API, remove it for now.
It might get added in the next release cycle, in a proper form.
@feature
This adds support for inlist structs, a special type of struct
that can only be used with inlists. This differs from regular
structs in a couple ways:
1) They are stored separately. Just like structs, enums, aliases
have their own storage, so do inlist structs.
2) They can't be @extern, nor they can be opaque.
3) They are their own type of typedecl.
4) When they contain only one field, this field must be a value
type always, cannot be a pointer.
Like regular structs, they can have arbitrary fields, and they
can have a pre-set free function via @free().
In C, the inlist structs will be generated exactly like ordinary
ones, except they will have EINA_INLIST before the first field.
Other binding generators can deal with them as they wish, for
example to provide high level interfaces to them.
This does not yet do the plumbing necessary to hook these into
the type system, nor it adds generator support.
@feature
Summary:
if there is a none beta class, then this class should not depend on beta
classes in parameters / event types / return types, parent inherits.
This adds this validation, so we can start to slowly to unbeta more and
more classes.
Reviewers: q66, zmike, cedric, segfaultxavi
Reviewed By: q66
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7999
Summary:
This adds two new complex types, slice<T> and rw_slice<T>. This
is necessary to make the type useful to bindings, as Eina_Slice
on its own says nothing about what it's carrying and that prevents
useful code from being generated outside of C.
@feature
Reviewers: bu5hm4n, segfaultxavi, lauromoura, cedric
Reviewed By: cedric
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7980
That means, it can only now be used on parameters and struct
fields, never aliased within typedefs. This simplifies the
logic so that we don't have ptr metadata buried several layers
deep.
Summary:
This allows using the @beta tag in classes, like this:
class @beta Efl.Foo extends Efl.Bar { ... }
This will surround the class definition in the .eo.h file with an
EFL_BETA_API_SUPPORT #define, equivalent to tag every method and
event with @beta.
Test Plan: Nothing changes since no class uses this tag yet
Reviewers: q66, bu5hm4n, zmike
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7933
We keep a hash tracking implements that were already errored on
so that we don't print some errors multiple times. The problem is
that it wasn't getting cleared when switching to a new inheritance
tree so errors from an interface implemented in multiple distinct
inheritance trees would only get printed once.
Since _extend_impl always marks the impl at least IMPL_STATUS_NONE,
we need to retrieve the original status before calling into it,
or it will get overwritten and will inadvertently disable some
of the checks.
We worked under the assumption that when inheriting callables
from a regular class, it's good enough to just set those as
fully implemented, because the underlying class is already
checked. This assumption is wrong, as the callables may contain
multiple implements pointing at the same function (consider when
a regular class implements just the get part of a property but
some underlying class implements it whole) - the old logic would
result in just the first reached implement (possibly incomplete)
being added into callables of the inheriting class, which results
in false positives.
Consider this example:
class A has a fully implemented property foo
class B inherits from A and partially implements foo
abstract C inherits from B
class D inherits from C
abstract C would go over B's implements, encounter the first
partial implementation of foo, adding it into its own callables
and marking it as fully implemented (because it came from an
already checked regular class B), which would result in the
other implement being skipped.
So make no assumptions and use the same logic for all class types.
Of course, this brings in another problem: some errors would now
get printed twice, because if you have a class A which has funcs
that are unimplemented and class B inheriting from it, errors would
get printed for A but also for B, which would include A's errors.
To battle that, introduce a "global" (well, local to the entry
point of the validator) hash tracking which implements have already
been errored on; and skip those appropriately.
It hasn't been necessary to keep these temporary buffers around
for quite a while, nobody just got around to remove them. Eolian
has a good formattable error logging system in its core now.
Also, use same erroring style on parts as on functions, i.e.
batch-print all the conflicts at once.
There isn't any more logic necessary because checks are still only
done on regular classes; we just need to make sure that composite
lists from its inheritance tree are accounted for.
if there is no free function, then there is no way that this value is
owned by the caller,
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7712
Each regular class can now have a section called 'composite',
which can contain interfaces and interfaces only. This defines
a list of interfaces that are allowed to be unimplemented on the
class, as it is assumed the class will be composited with some
other class implementing those interfaces.
Only regular classes can have this, as only regular classes can
be instantiated.
It will also be necessary to check whether the classes in the
section appear somewhere within the inheritance tree. For now,
this testing is not being done.
Example of usage:
composite {
Some.Magic.Interface;
Another.Magic.Interface;
}
directly in the class body.
base of the impl is where the function is defined, not where the missing
implementation is.
ref T5719
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7680
Summary:
This is needed in order to support checking the correct regular classes
in efl#.
ref T7240
Depends on D7673
Test Plan: run ninja test / make check
Reviewers: q66, felipealmeida, segfaultxavi
Reviewed By: felipealmeida
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7240
Differential Revision: https://phab.enlightenment.org/D7674
The checks are only done for regular classes. It's also disabled
by default as too many methods would be unimplemented.
Use EOLIAN_CLASS_UNIMPLEMENTED_WARN=1 to enable the errors.
It appears that NULL is not really usefull here, as this will lead to
errors later on. (void) will force the free function to just do nothing
and be later converted to a NOP.
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7629
This introduces a new keyword called required. It only works on mixins.
You can specify a list of regular/abstract classes in there.
Classes specified after the required keyword are later used to verify
the usage of the mixin. With this feature a mixin can define a list of
types that the inheriting object (the object that inherits from a mixin)
needs to fullfill, if one class that is required is not in the
implemented classes, then eolian will bail out.
Differential Revision: https://phab.enlightenment.org/D7584
This build was never complete and also was not maintained probebly.
It is also dropped in favour of meson which is cool, merged, works & is fast.
Differential Revision: https://phab.enlightenment.org/D7010
As per T7240, we intend to disallow multi-class inheritance in Eo
at some point. In order to achieve that, it is necessary to find
out which classes still use multi-class inheritance and change
them accordingly.
Eo multi-class inheritance is not actually multi-class, as doing
so will simply treat all the other classes as interfaces, which
is misleading and poor design on its own.
By setting EOLIAN_CLASS_REGULAR_AS_EXT_WARN environment variable,
Eolian will now warn about such classes, allowing them to be
fixed.
Closes T7365.
This new syntax separates the parent class from extensions, in
a familiar way to similar to e.g. Java. Since changing everything
at once is a lot of effort, implement it alongside for the time
being.
Eolian now separates 'parent' and 'extensions'. For regular
classes, parent is the first item in the inherits list and
extesions is the rest. For interfaces and mixins, parent is
NULL and extends is the inherits list.
The reason for this is the separation of them in syntax in near
future. It also slightly changes the behavior; since for interfaces
and mixins, parent is always NULL now, you can freely inherit from
all types of classes without needing to manually put an interface
type as the first item of the inherits list.
Previously, the EOLIAN_EVENT_REDEF_WARN environment variable
enabled extra checks that would include events in checking
conflicts against methods. Since this is probably not necessary
and naming events the same as methods is perfectly fine in itself,
relax this rule and check events completely independently.
In practice, this will disallow using the same name for two
events within the same inheritance tree, which is desirable
in longer term, but cannot be enabled just yet because we have
too many of those conflicts. But it also allows the events to
be named the same as methods or parts, which is fine and was not
possible before.
Summary:
Strings are const and if these are meant to be owned then it
should define its own special free func. Mstrings are mutable
and therefore can be owned and freed using standard free() by
default.
This fixes some warnings around the EFL caused by empty fallback
free funcs created by the eolian generator, and these mutable
strings were not being freed and potentially leaked.
Reviewers: bu5hm4n, stefan_schmidt
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7261
Taehyub Kim
Hermet Park
Xavi Artigas
Daniel Kolesa
Marcel Hollerbach
Daniel Kolesa
Lauro Moura
Marcel Hollerbach
Carsten Haitzler