Summary:
Eolian generator must have a parameter so it can generate the correct
symbol export/import macro for the API generated.
This makes it possible to define the symbols as being local to a
single DSO without the need to guard the generated headers or
generated source files with #define and #undef preprocessor
statements.
= The Rationale =
This patch is from a series of patches to rename EAPI symbols to
specific library DSOs.
EAPI was designed to be able to pass
`__attribute__ ((visibility ("default")))` for symbols with
GCC, which would mean that even if -fvisibility=hidden was used
when compiling the library, the needed symbols would get exported.
MSVC __almost__ works like GCC (or mingw) in which you can
declare everything as export and it will just work (slower, but
it will work). But there's a caveat: global variables will not
work the same way for MSVC, but works for mingw and GCC.
For global variables (as opposed to functions), MSVC requires
correct DSO visibility for MSVC: instead of declaring a symbol as
export for everything, you need to declare it as import when
importing from another DSO and export when defining it locally.
With current EAPI definitions, we get the following example
working in mingw and MSVC (observe it doesn't define any global
variables as exported symbols).
Example 1:
dll1:
```
EAPI void foo(void);
EAPI void bar()
{
foo();
}
```
dll2:
```
EAPI void foo()
{
printf ("foo\n");
}
```
This works fine with API defined as __declspec(dllexport) in both
cases and for gcc defining as
`__atttribute__((visibility("default")))`.
However, the following:
Example 2:
dll1:
```
EAPI extern int foo;
EAPI void foobar(void);
EAPI void bar()
{
foo = 5;
foobar();
}
```
dll2:
```
EAPI int foo = 0;
EAPI void foobar()
{
printf ("foo %d\n", foo);
}
```
This will work on mingw but will not work for MSVC. And that's why
LIBAPI is the only solution that works for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Reviewers: q66, vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12197
please note, not the return type, but the function.
When appending __attribute__((const)) to a function, the compiler is
told that its enough to call this function once in a function.
This is quite often happening when we are efl_data_scope_get and
efl_super in a function that is different from a implemented function.
The compiler now starts to remove the calls that aggressivly that we
need to ensure that these calls are not removed, which means, the static
function calls, and the eo init are now checking the return value of
these functions, to ensure that they are called.
Please note that you now have to be carefull when your app calls
eo_shutdown, if it does so, you *must* call it at the end of a function,
or never call class_get after that anymore.
Overall this improves elm test runs 0.1s which is fair i guess, the main
thing that is faster is textrendering, where is also the point where
this is the most beneficial.
Please note, this replaces 42 occurences of double _class_get() ... THAT
is a sign!
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D12057
Story:
This revision got landed twice, I do not know what happend, but when i
wanted to land that initially with git phab, something reseted the state
of this revision to the initial version, and also changed the
authorship. This time, this commit contains all changes, and the correct
authorship, sorry for the noise.
Summary:
Add @since tags at stable (not tagged with @beta) `.eo` c#/c++ tests. Doing so,
eolian_enforce_since shouldn't accuse at stable tests.
Depends on D11264
Resolves T8600
Reviewers: zmike, segfaultxavi, woohyun, bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8600
Differential Revision: https://phab.enlightenment.org/D11265
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Reviewed-by: Felipe Magno de Almeida <felipe@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D11046
Summary:
If a struct or enum field doesn't explicitly sets since information, then since
is inherited from struct documentation if it is available.
Reviewers: jptiz, Jaehyun_Cho, woohyun, q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8359
Differential Revision: https://phab.enlightenment.org/D10948
Summary:
This makes sure the user is warned if it ignores a return value that
could potentially be a memory leak.
This also makes possible to use `value {}` blocks with `@move` instead
of value-less properties with `@no_unused`.
Also removed the `@move` from canvas_text_async_layout as it is ignored
in the only place it is used.
Reviewers: q66
Reviewed By: q66
Subscribers: #reviewers, #committers, bu5hm4n, felipealmeida, cedric, segfaultxavi
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10601
Summary:
Instead of setting the default text at the library level, keep the
summary empty if nothing is provided.
The libeolian users them are free to check if the summary was actually
empty or a placeholder text was added.
ref T8309
Test Plan: Run attached tests
Reviewers: q66, segfaultxavi
Subscribers: cedric, brunobelo, #reviewers, felipealmeida, #committers
Tags: #efl
Maniphest Tasks: T8309
Differential Revision: https://phab.enlightenment.org/D10285
I'm afraid but this breaks the mono bindings too close to a release.
This also fixes the missing docs errors by adding a lot of inconsistent
placeholder text ("No description supplied.", "TBD") which will make
finding them later on more complicated.
I was the one that asked for this feature but it is not critical at this
point, so I suggest we explore some refinements (like T8291) before landing
this patch in its current state.
This reverts commit 2946cb3c32.
The things that require docs include classes, variables, typedecls,
events and methods/properties. Implements, params, returns, parts
and struct/enum fields don't require them.
Empty/whitespace only string does not count as documentation.
before @owned was not even expressed in the api definitions of the
generated APIs, this adds support for it.
@owned is now expressed with EFL_TRANSFER_OWNERSHIP in a arguments. And
that preprocessor directive is documented.
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D9369
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 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
Getter are usually not modifying there object. This is going to put a strong
limit on what a getter property for MVVM is, as it will prevent any side
effect on getting a property from a View.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7969
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 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
If legacy implementations are generated, eolian_gen now creates
a separate file for them and includes it. The file name convention
for that is <.c file name without ext>.legacy.<.c file name ext>
or <.c file name>.legacy.c if it has no ext, so for example
foo.eo.c becomes foo.eo.legacy.c and foo becomes foo.legacy.c.
The file is generated assuming there are any legacy APIs contained
inside the .eo file.
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.
This adds support for generating reflection functions for
properties. This support is basic for now, supporting only
primitive types and string(shares), it will be expanded later
as required.
@feature
Summary:
Eolian adds a per-class BETA guard (like EFL_UI_WIN_BETA) to any method tagged
as @beta. This means that any app (and the EFL code) wanting to use BETA features
has to enable them class by class, which is cumbersome.
This commit replaces the individual guards with the global EFL_BETA_API_SUPPORT
guard, so apps only need to define one symbol to access BETA features.
Any usage of the per-class guards has been removed from the EFL code and examples.
When building EFL the global guard is defined by configure, so all EFL methods
already have access to BETA API.
Efl_Core.h and Efl_Ui.h no longer define EFL_BETA_API_SUPPORT. Apps wanting to
use BETA API have to define this symbol before including any EFL header
(It has been added to the examples requiring it).
Test Plan:
make && make check && make examples still work, but there's a lot less #defines
in the code
Reviewers: zmike, bu5hm4n, q66
Reviewed By: q66
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T6788
Differential Revision: https://phab.enlightenment.org/D7924
As in the previous commit explained, we want to get rid of class
functions in eo, and make them just c functions right away.
This commit removes the class parameter from the eo_class_function_set
call, and adjusts the tests to not depend on class functions anymore.
Class functions are now not tested anymore, tests that used them as a
way to test *things* are adjusted to test them now with object
functions, tests that just tested the working of class functions are
dropped.
This fixes T7675.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7902
Until this commit eo did class functions as part of the vtable, which
enabled those functions to be overwritten in classes inheriting another
class. However in task T7675 we decided that this is not really good for
bindings, as most OOP languages do not support this sort of feature.
After this commit eolian realizes class function completly outside of
the vtable, the c-symbol that is the class funciton is now just directly
redirecting to a implementation, without the involvement of the vtable.
This also means a change to the syntax created by eo:
Calling before:
class_function(CLASS_A);
Calling after:
class_function();
Implementation before:
class_function(const Eo *obj, void *pd) { ... }
Implementation after:
class_function(void) { ... }
This fixes T7675.
Co-authored-by: lauromauro <lauromoura@expertisesolutions.com.br>
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7901
The next commit will bring support for something like reflection. This
commit prepares the whole tree for getting another argument in
efl_class_functions_set.
ref T7681
Differential Revision: https://phab.enlightenment.org/D7882
this commit is a first step in order to add free functions to all the
types that are owned.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D7627
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.
Felipe Magno de Almeida
Marcel Hollerbach
Lucas Cavalcante de Sousa
Cedric BAIL
Felipe Magno de Almeida
Lauro Moura
Xavi Artigas
Daniel Kolesa
Daniel Kolesa