The @by_ref qualifier is now allowed on parameters, returns and
struct fields in the usual qualifier section. It will mean that
this type is passed around by reference, and will only be allowed
on types that are not already pointer-like.
The @move qualifier will replace @owned as one with a clearer
meaning. It means "transfer of ownership". It has the same semantics
as the current @owned, i.e. on return values it transfers ownership
of the value to the caller, on parameters it transfers ownership
to the callee (the inverse is the default when not specified).
On struct fields, it means the field will transfer together with
the struct that contains it.
In the end this was just a failed experiment that didn't turn
out to be practical. For now, revert back to ptr(const(T)) until
a proper replacement for pointer syntax is added.
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.
This implements initial support for specifying unit versions.
The default version is 1, specifying the basic feature level.
If you want to specify another version, you need to specify
something like `#version 2` at the beginning of the .eo or
.eot file; the version number must be higher than 0 and lower
than USHRT_MAX (typically 65536).
The beginning of the file is now called the "header section";
other things may be added into the header section later.
Version cannot be specified twice, and it cannot be specified
once other contents (like types or class definition) appear.
Comments do not count as other contents, so those are fine
to appear before #version.
@feature
@warn_unused in syntax is now called @no_unused - this is because
"warning about unused" is a C thing (or rather, an extension to C)
and various languages might want to use stricter behavior for this.
Its associated API does the reverse now - it lets you query whether
being unused is allowed at all. This is to match future behavior
of Eolian (once it supports versioning) that will likely reverse it.
@feature
This has been deprecated for a while and is not strictly necessary
- as a part of an effort to stabilize Eolian, remove this. Eolian
will eventually gain support for versioning and use a reversed
behavior (i.e. no NULL by default), but the API it wlll use for
that will be very different. Features can always be added, it's
much harder to drop them.
@feature
This was an experiment that never properly took off and was never
used by any generator. Its use was highly variable, so it could
not be relied upon. We will still want to reverse the current
behavior eventually (no null by default), but that will be
done with eo file versioning in the future.
@feature
This is to prepare for type/class renaming support. This adds
the necessary API to retrieve C-specific names. Other refactoring
is necessary elsewhere for now.
This also renames the old API eolian_class_c_name_get to
eolian_class_c_macro_get to avoid conflict as well as clarify
the intention.
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:
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
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.
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.
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 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.
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.
Daniel Kolesa
Xavi Artigas
Taehyub Kim
Daniel Kolesa
Marcel Hollerbach
Carsten Haitzler