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.
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 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.
Set the EOLIAN_EVENT_NO_TYPE_WARN environment variable to enable
those warnings during Eolian usage. They will be considered a part
of the validation then.
Use the void type for events to suppress the warning.
This is necessary because inheritance trees need to be validated
individually for proper name conflict checks. It also prevents
eina_hash_add related errors.
Doc refs no longer introduce new dependencies into files. Instead,
they're parsed globally, and any doc ref lookup is also made
globally. This allows unit based dependencies to correspond more
to what files actually really need at compile time/runtime, with
docs being irrelevant to that; it also simplifies the API.
The doc resolution API now takes Eolian_State instead of
Eolian_Unit, too.
Eolian doc objects now bundle debug information necessary to
provide correct line/column numbers. It is not possible to get
this information cirectly from the text, as it's reformatted and
contains no extra whitespace or newlines beyond paragraph
separators.
Fixes T6701.
This change finally introduces deferred parsing of inherits to
Eolian, after a long time and many iterations. That means instead
of parsing inherits directly as part of the main file's parse pass,
they're pushed into a queue and parsed later. The validation engine
was modified to properly fill in the remaining info afterwards.
This may introduce breakages but I haven't noticed any. It also
properly unlocks cyclic dependency support in Eolian.
Additionally, this also introduces checks for duplicates in class
inherits (class Foo(Bar, Bar) is no longer possible) and it adds
stricter name checks, so you can no longer have a class Foo.Bar
and refer to it as Foo_Bar in implements. This was actually never
meant to be supported, but the check was previously broken.
@feature
For one, the hash has to be populated once per inheritance tree
and the skipping on already-validated funcs was interfering with
that as the function might have been validated in another
inheritance tree already.
Also, if a class appeared multiple times in an inheritance tree,
as is common with e.g. Efl.Object, it would get added into the
hash the first time and then checked against the second time,
which would result in a strange error message about the
function being redefined in its own class.
So now we prevent both cases from happening.
This makes sure that duplicate method/part/etc checks are done on
every database update, removing the need for clunky toplevel
checks and improving reliability. It also sacrifices some
performance but it shouldn't be too bad (if a class is already
validated, some checks are avoided to speed things up).
Daniel Kolesa
Cedric BAIL
Daniel Kolesa
Mike Blumenkrantz