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.
This is necessary even when parsing a single file because there
may be parsed results directly in the staging area introduced by
doc references, those wouldn't get correctly validated and would
be left in an inconsistent and unusable state.
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.
This is much like 'import' but doesn't add the imported file into
the dependency list for the current file. This is to enable doc
reference validation to remain functional without needlessly
introducing file dependencies just to satisfy it.
The issue was that standalone-parsed files (outside of dependencies
of some other unit) were not being included in that dependency tree
(obviously) which resulted in their own dependency tree being
excluded from merging, causing the database hashes to lack the
necessary elements.
To fix this, I trigger merging of the "standalone" dependency trees
separately, by calling _merge_units from defer parsing cb.
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.
This is cleaner than adding into a hash manually. Additionally, it
is now possible to request that the file be parsed not as a dep,
but rather standalone, which will be useful later.
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.
Previously, when an error happened in Eolian, the state was left
in a presumably unusable and inconsistent condition. This work
aims to change that, as all changes are committed into a staging
area before being validated and merged back into main state.
This is not yet complete, as units and by-file lookups are not
currently involved in the rollback. This will change in the
subsequent commits.
@feature
Unlike panic, this will be used to handle regular errors
such as parse errors. There will be no jumps and you
will be able to pass in a pointer to get the error
data into some local memory. That way you will be
able to override printing error messages.
As nearly every Eolian handle is backed by an Eolian_Object,
this information is now publicly exposed and has an API. This
opens up an array of new possibilities for tooling, as you
can now externally query file names, line numbers etc.,
as well as cast arbitrary handles to Eolian_Object pointers
and back.
This will be expanded later and it will replace the Declaration
system, as it's cleaner, better integrated and more versatile.
@feature
This finally enables looking up things from the current unit
rather than from a backing storage in the Eolian state. This
also means that the benefits of having a unit system will
finally be visible.
This makes sure variables are stored as well as types within their
respective units. Also, declarations are now refcounted just like
any other Eolian object.
Eolian now properly merges all unit hashes (e.g. unit A has
children B and C, hashes of B and C are merged into A's hashes
in order to be able to look up B and C's contents via A) and
maintains a (potentially cyclic) children graph.
Not everything is yet added into all hashes, but at least the
building blocks are there.
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.
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.
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).
Units now form an actual tree stored in their own hash. This will
later replace all global state of Eolian, by introducing a master
unit that you will pass around.
The check was only done on one of the two functions, resulting in some
unwanted warnings.
EOLIAN_WARN_FUNC_DUPLICATES=1 will show non-beta warnings.
EOLIAN_WARN_FUNC_DUPLICATES=2 will still show all warnings.
This disallows deeply nested pointers, you can only explicitly
ptr() on types that are strictly value types.
For a few cases where it was necessary to override this behavior,
you can use legacy(ptr(x)) as a temporary measure.
Daniel Kolesa
Marcel Hollerbach
Marcel Hollerbach
Carsten Haitzler
Felipe Magno de Almeida
Cedric BAIL
Daniel Kolesa
Mike Blumenkrantz
Vincent Torri
Jean-Philippe Andre
Lauro Moura
Pawel Aksiutowicz