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
This information has been stored and used in Eolian until now
but not exposed to the API user. While there are roundabout ways
to retrieve the class for an event, this one is direct and costs
us nothing.
This will make it easier for generators and utilities to retrieve
the class that implemented a method/property/etc rather than the
class the implement was originally defined for. Thanks to this
it will no longer be necessary to carry the class pointer around
the place.
Summary:
This tagging keyword explicitly asks, for bindings that support it,
that the constructor's parameters are added to the class constructor.
Allowing the user to instantiate the class and call the constructor in
a straightforward way.
Reviewers: q66, woohyun, bu5hm4n, Jaehyun_Cho, segfaultxavi
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers, lauromoura
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7221
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
It is not necessary to check entire classes/typedecls/variables
when referenced, as that also checks their contents and adds
false negatives. It is enough to simply add their own unit
as a 'used' dependency and let the system do the work, besides
for actual declarations in the checked file.