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
We must check all pointerness first, and append NULL as default
when that applies, because @by_ref is not carried in the typedecl
info. Therefore, it would result in a false positive and try to
make a zeroed struct, which we don't want.
This is unnecessary because for all contexts where type is
relevant the validator already makes sure the type and expression
match correctly, so you don't ever need to re-validate it. If you
are doing a generic case and are not sure, just use MASK_ALL.
This is for consistency with the new eolian_class_c_macro_get
as well as for better clarity, as c_name_get is already provided
by Object and refers to something else.
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:
Small patch to fix a resource leak detected by Coverity. Coverity
reports that 'refls' going out of scope leaks the storage it points
to, so let's free it before we leave the function.
Fixes Coverity CID1399099
Depends on D8309
Reviewers: raster, cedric, q66, zmike, bu5hm4n, stefan
Reviewed By: q66
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8310
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
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
we forgot to generate the legacy function. This no now added back.
ref D8029
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D8037
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.
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
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 fixes a lot of different warnings in the efl_mono test generation.
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7730
this avoid warings about keys not beeing used in the fallback function.
Reviewed-by: Daniel Kolesa <daniel@octaforge.org>
Differential Revision: https://phab.enlightenment.org/D7630
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 changes a lot of things all across the EFL. Previously,
methods tagged @const had both their external prototype and
internal impl generated with const on object, while property
getters only had const on the external API. This is now changed
and it all has const everywhere.
Ref T6859.
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.
Most of the time you need to retrieve the class from the string
anyway, so remove this relic of old Eolian and gain some small
performance benefits and extra convenience.
Subtly breaks API but everything should be updated.
Because of a typo in generator source (and overlooked error in
tests) we were previously generating incorrect code for setters
with the @auto qualifier. This was brought up in D5306 and is
now fixed.
Coverity reports that the eina_strbuf 'param_call' leaks when it goes
out of scope here, so fix the leak by freeing the strbuf
Fixes CID1381502
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
It's a complex struct but defined in EO as a simple struct. ABI-wise
it's equivalent to Eina_Rectangle. Some macros that use Eina_Rectangle
also work on Eina_Rect out of the box, most of the code dealing with
x,y,w,h will require no modifications either.
But Eina_Rect provides direct access to a size or position 2d component,
as well as the usual x,y,w,h. The field "rect" is provided as a
convenience for code dealing with both Eina_Rectangle and Eina_Rect. We
may or may not require it.
Note: Size2D could use unsigned values but I have spotted a few places
in the code that actually use -1 to indicate invalid size (as opposed to
0x0).
@feature