This refactors ownability checks so that they're only performed
in contexts where @move can be specified, which both helps
with performance and enables later removal of ownability info
from types themselves.
This changes the behavior of the existing env var to only check
unimplemented functions in stable APIs by default. Beta checks
can be enabled with an additional environment var, so use
EOLIAN_CLASS_UNIMPLEMENTED_WARN for stable and
EOLIAN_CLASS_UNIMPLEMENTED_BETA_WARN for extra beta checks.
This restricts disallowing value types to containers that can own
them.
It also disallows usage of @owned on those view-only containers,
as that makes no sense.
You can now declare errors like this:
error Foo = "message"; [[documentation]]
Then you can use them as types like this:
foo {
return: error(Error1, Error2, ...);
}
They have a separate type category and storage. They are checked
for redefinitions the same as anything else though. This does
not add any generator support nor it adds any advanced checking.
Ref T6890
This adds a new unified syntax for giving declarations C names.
Classes: class @c_name(Foo) Foo ...
Types: type @c_name(Foo) Foo: Bar ...
Structs: struct @c_name(Foo) Foo ...
and so on. Type instances properly inherit those. This also cleans
up some other parts of the source code.
Fixes T6716.
Summary:
The C# bindings turn parts into class properties, so part names cannot clash
with method names.
However, a "Part" prefix has been recently added, just like it was done for
events, and therefore this eolian restriction can be lifted.
With this patch part name clashes are only checked among parts, just like it
is done for events.
Relates to D8582
Test Plan: Everything still builds, because we have no part-method name clashes in the tree, but now they are possible.
Reviewers: q66, SanghyeonLee
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9031
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
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
Daniel Kolesa
Xavi Artigas
Hermet Park
Marcel Hollerbach
Daniel Kolesa