enlightenment/efl
enlightenment
/
efl
8
7
Fork 14
Code Issues 13 Pull Requests 1 Projects Releases Wiki Activity
efl/src/lib/eolian/database_function_api.c

398 lines
12 KiB
C
Raw Normal View History

fix config.h inclusion across the tree
2014-09-23 12:48:16 -07:00
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
#include <Eina.h>
#include "eolian_database.h"
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eolian_Object_Scope
eolian: support @protected for accessors (get/set) Previously it was only possible to set it for the whole property. @feature
2016-06-09 08:54:43 -07:00
eolian_function_scope_get(const Eolian_Function *fid, Eolian_Function_Type ftype)
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
{
eolian: consistent and cleaner error values from APIs Now all error/unknown/etc values returned from APIs are zero, previously it was a mix of zeroes and minus ones. Also, some enums that had no error/invalid value before have one now, which allows for better distinction between what is an error and what is an intended result.
2017-01-13 06:15:10 -08:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, EOLIAN_SCOPE_UNKNOWN);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_UNRESOLVED, EOLIAN_SCOPE_UNKNOWN);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_PROPERTY, EOLIAN_SCOPE_UNKNOWN);
eolian: support @protected for accessors (get/set) Previously it was only possible to set it for the whole property. @feature
2016-06-09 08:54:43 -07:00
switch (ftype)
{
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
case EOLIAN_METHOD:
if (fid->type != EOLIAN_METHOD)
eolian: consistent and cleaner error values from APIs Now all error/unknown/etc values returned from APIs are zero, previously it was a mix of zeroes and minus ones. Also, some enums that had no error/invalid value before have one now, which allows for better distinction between what is an error and what is an intended result.
2017-01-13 06:15:10 -08:00
return EOLIAN_SCOPE_UNKNOWN;
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
return fid->get_scope;
case EOLIAN_PROP_GET:
if ((fid->type != EOLIAN_PROP_GET) && (fid->type != EOLIAN_PROPERTY))
eolian: consistent and cleaner error values from APIs Now all error/unknown/etc values returned from APIs are zero, previously it was a mix of zeroes and minus ones. Also, some enums that had no error/invalid value before have one now, which allows for better distinction between what is an error and what is an intended result.
2017-01-13 06:15:10 -08:00
return EOLIAN_SCOPE_UNKNOWN;
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
return fid->get_scope;
case EOLIAN_PROP_SET:
if ((fid->type != EOLIAN_PROP_SET) && (fid->type != EOLIAN_PROPERTY))
eolian: consistent and cleaner error values from APIs Now all error/unknown/etc values returned from APIs are zero, previously it was a mix of zeroes and minus ones. Also, some enums that had no error/invalid value before have one now, which allows for better distinction between what is an error and what is an intended result.
2017-01-13 06:15:10 -08:00
return EOLIAN_SCOPE_UNKNOWN;
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
return fid->set_scope;
default:
eolian: consistent and cleaner error values from APIs Now all error/unknown/etc values returned from APIs are zero, previously it was a mix of zeroes and minus ones. Also, some enums that had no error/invalid value before have one now, which allows for better distinction between what is an error and what is an intended result.
2017-01-13 06:15:10 -08:00
return EOLIAN_SCOPE_UNKNOWN;
eolian: support @protected for accessors (get/set) Previously it was only possible to set it for the whole property. @feature
2016-06-09 08:54:43 -07:00
}
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eolian_Function_Type
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
eolian_function_type_get(const Eolian_Function *fid)
{
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, EOLIAN_UNRESOLVED);
return fid->type;
}
eolian: remove the need to pass prefix to eolian_function_full_c_name_get
2014-09-25 07:37:18 -07:00
static const char *
eolian: move from eo_prefix to c_prefix
2019-05-09 07:16:42 -07:00
_get_c_prefix(const Eolian_Function *foo_id, char *buf)
eolian: remove the need to pass prefix to eolian_function_full_c_name_get
2014-09-25 07:37:18 -07:00
{
eolian: move from eo_prefix to c_prefix
2019-05-09 07:16:42 -07:00
if (foo_id->klass->c_prefix)
return foo_id->klass->c_prefix;
eolian: use c_name when building complex C symbol names
2019-05-30 08:00:52 -07:00
strcpy(buf, foo_id->klass->base.c_name);
eolian: remove the need to pass prefix to eolian_function_full_c_name_get
2014-09-25 07:37:18 -07:00
eina_str_tolower(&buf);
return buf;
}
eolian: remove all duplicated affix Summary: Currently eolian abbreviates when only the last word of class name and the first word of method name are same, but this patch abbreviates generated c name of function to remove all duplicated affix. For example, "efl_io_closer_fd_closer_fd_set" will be "efl_io_closer_fd_set". Reviewers: jpeg Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D4430 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2016-11-28 10:55:27 -08:00
static char *
_get_abbreviated_name(const char *prefix, const char *fname)
{
Eina_Strbuf *buf = eina_strbuf_new();
const char *last_p = strrchr(prefix, '_');
last_p = (last_p) ? (last_p + 1) : prefix;
const char *tmp = strstr(fname, last_p);
int len = strlen(last_p);
if ((tmp) &&
((tmp == fname) || (*(tmp - 1) == '_')) &&
((*(tmp + len) == '\0') || (*(tmp + len) == '_')))
{
int plen = strlen(prefix);
len += (tmp - fname);
if ((plen >= len) && !strncmp(prefix + plen - len, fname, len))
{
eina_strbuf_append_n(buf, prefix, plen - len);
}
}
if (eina_strbuf_length_get(buf) == 0)
eina_strbuf_append_printf(buf, "%s_", prefix);
eina_strbuf_append(buf, fname);
char *ret = eina_strbuf_string_steal(buf);
eina_strbuf_free(buf);
return ret;
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Stringshare *
eolian: improve function_full_c_name_get API It's now generalized to work properly with legacy functions as well as correctly append suffixes. Thus, it can be easily used with the documentation generator and in other places. @feature
2015-07-08 04:09:56 -07:00
eolian_function_full_c_name_get(const Eolian_Function *foo_id,
eolian: remove legacy handling API and most of generation 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
2019-03-08 06:58:52 -08:00
Eolian_Function_Type ftype)
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
{
eolian: remove the need to pass prefix to eolian_function_full_c_name_get
2014-09-25 07:37:18 -07:00
char tbuf[512];
eolian: Add builtin type "strbuf" Refers to Eina_Strbuf*
2017-11-21 22:44:06 -08:00
tbuf[0] = '\0';
eolian: move from eo_prefix to c_prefix
2019-05-09 07:16:42 -07:00
const char *prefix = (ftype != EOLIAN_FUNCTION_POINTER) ? _get_c_prefix(foo_id, tbuf): tbuf;
eolian: improve function_full_c_name_get API It's now generalized to work properly with legacy functions as well as correctly append suffixes. Thus, it can be easily used with the documentation generator and in other places. @feature
2015-07-08 04:09:56 -07:00
if (!prefix)
return NULL;
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
const char *funcn = eolian_function_name_get(foo_id);
Eina_Strbuf *buf = eina_strbuf_new();
Eina_Stringshare *ret;
eolian: remove all duplicated affix Summary: Currently eolian abbreviates when only the last word of class name and the first word of method name are same, but this patch abbreviates generated c name of function to remove all duplicated affix. For example, "efl_io_closer_fd_closer_fd_set" will be "efl_io_closer_fd_set". Reviewers: jpeg Subscribers: cedric Differential Revision: https://phab.enlightenment.org/D4430 Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
2016-11-28 10:55:27 -08:00
char *abbr = _get_abbreviated_name(prefix, funcn);
eina_strbuf_append(buf, abbr);
free(abbr);
eolian: improve function_full_c_name_get API It's now generalized to work properly with legacy functions as well as correctly append suffixes. Thus, it can be easily used with the documentation generator and in other places. @feature
2015-07-08 04:09:56 -07:00
if ((ftype == EOLIAN_PROP_GET) || (ftype == EOLIAN_PROPERTY))
eina_strbuf_append(buf, "_get");
else if (ftype == EOLIAN_PROP_SET)
eina_strbuf_append(buf, "_set");
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
ret = eina_stringshare_add(eina_strbuf_string_get(buf));
eina_strbuf_free(buf);
return ret;
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API const Eolian_Implement *
eolian: remove/add APIs and clean up implements system As there is no need to have separate is_auto, is_empty and is_pure_virtual for functions and implements (each function has its own base implement by default) I removed the function ones. Instead, I added a way to retrieve a function's base implement so that you can instead do the checks on the implement even when you only have the function. I also moved base implement build directly into the parser instead of the database filler. That allows for significant cleanup. I also removed distinction of implement pointers in Eolian_Function for get and set as implements now always contain an entire thing so the pointer was always the same anyway. Things should still behave more or less the same, but ordering of generated functions has changed because ordering of implements has changed.
2017-01-16 06:51:11 -08:00
eolian_function_implement_get(const Eolian_Function *fid)
eolian: APIs to check auto/empty on a function
2014-09-03 06:25:50 -07:00
{
eolian: remove/add APIs and clean up implements system As there is no need to have separate is_auto, is_empty and is_pure_virtual for functions and implements (each function has its own base implement by default) I removed the function ones. Instead, I added a way to retrieve a function's base implement so that you can instead do the checks on the implement even when you only have the function. I also moved base implement build directly into the parser instead of the database filler. That allows for significant cleanup. I also removed distinction of implement pointers in Eolian_Function for get and set as implements now always contain an entire thing so the pointer was always the same anyway. Things should still behave more or less the same, but ordering of generated functions has changed because ordering of implements has changed.
2017-01-16 06:51:11 -08:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, NULL);
return fid->impl;
eolian: APIs to check auto/empty on a function
2014-09-03 06:25:50 -07:00
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Bool
eolian: rename is_class api for functions to is_static Still needs restriction to classes only etc to be done later. Ref https://phab.enlightenment.org/T8118 Ref https://phab.enlightenment.org/T7675
2019-08-16 07:32:13 -07:00
eolian_function_is_static(const Eolian_Function *fid)
eolian: add support for class functions
2014-07-24 04:05:12 -07:00
{
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, EINA_FALSE);
eolian: rename @class on methods to @static Ref https://phab.enlightenment.org/T8118 Ref https://phab.enlightenment.org/T7675
2019-08-16 07:27:00 -07:00
return fid->is_static;
eolian: add support for class functions
2014-07-24 04:05:12 -07:00
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Bool
eolian: Added eolian_function_is_constructor(). This patch adds a list of strings called 'ctor_of' to _Eolian_Function. This list will contain all classes in which this function is a constructing function. ctor_of is filled in two moments: * When filling the constructors of a class, class->full_name is inserted in the 'ctor_of' of each constructor's function. * When filling the implements of a class, if the function is a constructor of its superclass it also becomes a constructor of the current class, so class->full_name is also inserted in the 'ctor_of' of each implement's function. eolian_function_is_constructor gets a func and klass arguments. It goes through ctor_of of func and returns EINA_TRUE if klass->full_name is found, otherwise it returns EINA_FALSE.
2014-09-12 12:51:37 -07:00
eolian_function_is_constructor(const Eolian_Function *fid, const Eolian_Class *klass)
{
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, EINA_FALSE);
eolian: give objects names, and reduce duplication
2018-03-08 10:30:40 -08:00
Eina_Stringshare *s = eina_stringshare_ref(klass->base.name);
eolian: Added eolian_function_is_constructor(). This patch adds a list of strings called 'ctor_of' to _Eolian_Function. This list will contain all classes in which this function is a constructing function. ctor_of is filled in two moments: * When filling the constructors of a class, class->full_name is inserted in the 'ctor_of' of each constructor's function. * When filling the implements of a class, if the function is a constructor of its superclass it also becomes a constructor of the current class, so class->full_name is also inserted in the 'ctor_of' of each implement's function. eolian_function_is_constructor gets a func and klass arguments. It goes through ctor_of of func and returns EINA_TRUE if klass->full_name is found, otherwise it returns EINA_FALSE.
2014-09-12 12:51:37 -07:00
Eina_Bool r = !!eina_list_search_sorted_list
(fid->ctor_of, EINA_COMPARE_CB(strcmp), s);
eina_stringshare_del(s);
return r;
}
eolian: allow keys/values in property get/set Sometimes it is necessary to specify a different set of values for a getter or a setter. This commit allows such specializations. This also renders @const_get and @const_set useless (soon to be removed). To function correctly, this required adjustment of several public APIs as well as deprecation of eolian_function_parameter_get_by_name. This function was not used in any generator and was pretty much useless in the first place, so it was removed. @fix
2015-05-20 09:42:00 -07:00
static Eina_List *
_get_prop_keys(const Eolian_Function *fid, Eolian_Function_Type ftype)
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
{
eolian: allow keys/values in property get/set Sometimes it is necessary to specify a different set of values for a getter or a setter. This commit allows such specializations. This also renders @const_get and @const_set useless (soon to be removed). To function correctly, this required adjustment of several public APIs as well as deprecation of eolian_function_parameter_get_by_name. This function was not used in any generator and was pretty much useless in the first place, so it was removed. @fix
2015-05-20 09:42:00 -07:00
Eina_List *l = fid->prop_keys_get;
if (ftype == EOLIAN_PROP_SET) l = fid->prop_keys_set;
if (!l) return fid->prop_keys;
return l;
}
static Eina_List *
_get_prop_values(const Eolian_Function *fid, Eolian_Function_Type ftype)
{
Eina_List *l = fid->prop_values_get;
if (ftype == EOLIAN_PROP_SET) l = fid->prop_values_set;
if (!l) return fid->prop_values;
return l;
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Iterator *
eolian: distinguish between get/set for property keys/values retrieval
2015-05-20 09:03:14 -07:00
eolian_property_keys_get(const Eolian_Function *fid, Eolian_Function_Type ftype)
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
{
eolian: allow keys/values in property get/set Sometimes it is necessary to specify a different set of values for a getter or a setter. This commit allows such specializations. This also renders @const_get and @const_set useless (soon to be removed). To function correctly, this required adjustment of several public APIs as well as deprecation of eolian_function_parameter_get_by_name. This function was not used in any generator and was pretty much useless in the first place, so it was removed. @fix
2015-05-20 09:42:00 -07:00
Eina_List *l = NULL;
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, NULL);
eolian: distinguish between get/set for property keys/values retrieval
2015-05-20 09:03:14 -07:00
if (ftype != EOLIAN_PROP_GET && ftype != EOLIAN_PROP_SET)
return NULL;
eolian: allow keys/values in property get/set Sometimes it is necessary to specify a different set of values for a getter or a setter. This commit allows such specializations. This also renders @const_get and @const_set useless (soon to be removed). To function correctly, this required adjustment of several public APIs as well as deprecation of eolian_function_parameter_get_by_name. This function was not used in any generator and was pretty much useless in the first place, so it was removed. @fix
2015-05-20 09:42:00 -07:00
l = _get_prop_keys(fid, ftype);
return (l ? eina_list_iterator_new(l) : NULL);
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Iterator *
eolian: distinguish between get/set for property keys/values retrieval
2015-05-20 09:03:14 -07:00
eolian_property_values_get(const Eolian_Function *fid, Eolian_Function_Type ftype)
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
{
eolian: allow keys/values in property get/set Sometimes it is necessary to specify a different set of values for a getter or a setter. This commit allows such specializations. This also renders @const_get and @const_set useless (soon to be removed). To function correctly, this required adjustment of several public APIs as well as deprecation of eolian_function_parameter_get_by_name. This function was not used in any generator and was pretty much useless in the first place, so it was removed. @fix
2015-05-20 09:42:00 -07:00
Eina_List *l = NULL;
eolian: distinguish between get/set for property keys/values retrieval
2015-05-20 09:03:14 -07:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, NULL);
if (ftype != EOLIAN_PROP_GET && ftype != EOLIAN_PROP_SET)
return NULL;
eolian: allow keys/values in property get/set Sometimes it is necessary to specify a different set of values for a getter or a setter. This commit allows such specializations. This also renders @const_get and @const_set useless (soon to be removed). To function correctly, this required adjustment of several public APIs as well as deprecation of eolian_function_parameter_get_by_name. This function was not used in any generator and was pretty much useless in the first place, so it was removed. @fix
2015-05-20 09:42:00 -07:00
l = _get_prop_values(fid, ftype);
return (l ? eina_list_iterator_new(l) : NULL);
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Iterator *
eolian: eolian_parameters_get -> eolian_function_parameters_get
2014-07-23 06:17:19 -07:00
eolian_function_parameters_get(const Eolian_Function *fid)
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
{
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, NULL);
eolian: function pointers First steps toward explicit function pointer support in eolian. To declare a function pointer type, use the following syntax, similar to a regular eolian method declaration. function FunctionName { params { ... } return: Return type }
2017-04-07 09:54:55 -07:00
if (fid->type != EOLIAN_METHOD && fid->type != EOLIAN_FUNCTION_POINTER)
eolian: distinguish between get/set for property keys/values retrieval
2015-05-20 09:03:14 -07:00
return NULL;
eolian: fix NULL checks in APIs that return iterators + fix tests
2014-07-23 05:44:42 -07:00
return (fid->params ? eina_list_iterator_new(fid->params) : NULL);
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API const Eolian_Type *
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
eolian_function_return_type_get(const Eolian_Function *fid, Eolian_Function_Type ftype)
{
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, NULL);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_UNRESOLVED, NULL);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_PROPERTY, NULL);
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
switch (ftype)
{
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
case EOLIAN_METHOD:
eolian: add support for function pointers in utility APIs
2019-09-03 06:03:44 -07:00
case EOLIAN_FUNCTION_POINTER:
if (fid->type != ftype)
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
return NULL;
return fid->get_ret_type;
case EOLIAN_PROP_GET:
if ((fid->type != EOLIAN_PROP_GET) && (fid->type != EOLIAN_PROPERTY))
return NULL;
return fid->get_ret_type;
case EOLIAN_PROP_SET:
if ((fid->type != EOLIAN_PROP_SET) && (fid->type != EOLIAN_PROPERTY))
return NULL;
return fid->set_ret_type;
default:
return NULL;
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
}
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API const Eolian_Expression *
eolian: s/dflt/default/g
2014-07-11 06:30:22 -07:00
eolian_function_return_default_value_get(const Eolian_Function *fid, Eolian_Function_Type ftype)
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
{
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, NULL);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_UNRESOLVED, NULL);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_PROPERTY, NULL);
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
switch (ftype)
{
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
case EOLIAN_METHOD:
eolian: add support for function pointers in utility APIs
2019-09-03 06:03:44 -07:00
case EOLIAN_FUNCTION_POINTER:
if (fid->type != ftype)
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
return NULL;
return fid->get_ret_val;
case EOLIAN_PROP_GET:
if ((fid->type != EOLIAN_PROP_GET) && (fid->type != EOLIAN_PROPERTY))
return NULL;
return fid->get_ret_val;
case EOLIAN_PROP_SET:
if ((fid->type != EOLIAN_PROP_SET) && (fid->type != EOLIAN_PROPERTY))
return NULL;
return fid->set_ret_val;
default:
return NULL;
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
}
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API const Eolian_Documentation *
eolian: add documentation handling API This adds new APIs that deal with the new documentation syntax provided by Eolian. The old doc comment APIs are considered deprecated from now on and will be removed. @feature
2015-06-03 08:16:53 -07:00
eolian_function_return_documentation_get(const Eolian_Function *fid, Eolian_Function_Type ftype)
{
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, NULL);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_UNRESOLVED, NULL);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_PROPERTY, NULL);
eolian: add documentation handling API This adds new APIs that deal with the new documentation syntax provided by Eolian. The old doc comment APIs are considered deprecated from now on and will be removed. @feature
2015-06-03 08:16:53 -07:00
switch (ftype)
{
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
case EOLIAN_METHOD:
eolian: add support for function pointers in utility APIs
2019-09-03 06:03:44 -07:00
case EOLIAN_FUNCTION_POINTER:
if (fid->type != ftype)
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
return NULL;
return fid->get_return_doc;
case EOLIAN_PROP_GET:
if ((fid->type != EOLIAN_PROP_GET) && (fid->type != EOLIAN_PROPERTY))
return NULL;
return fid->get_return_doc;
case EOLIAN_PROP_SET:
if ((fid->type != EOLIAN_PROP_SET) && (fid->type != EOLIAN_PROPERTY))
return NULL;
return fid->set_return_doc;
default:
return NULL;
eolian: add documentation handling API This adds new APIs that deal with the new documentation syntax provided by Eolian. The old doc comment APIs are considered deprecated from now on and will be removed. @feature
2015-06-03 08:16:53 -07:00
}
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Bool
eolian: rename @warn_unused and its associated API @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
2019-05-26 08:41:22 -07:00
eolian_function_return_allow_unused(const Eolian_Function *fid,
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
Eolian_Function_Type ftype)
{
eolian: rename @warn_unused and its associated API @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
2019-05-26 08:41:22 -07:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, EINA_TRUE);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_UNRESOLVED, EINA_TRUE);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_PROPERTY, EINA_TRUE);
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
switch (ftype)
{
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
case EOLIAN_METHOD:
eolian: add support for function pointers in utility APIs
2019-09-03 06:03:44 -07:00
case EOLIAN_FUNCTION_POINTER:
if (fid->type != ftype)
eolian: rename @warn_unused and its associated API @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
2019-05-26 08:41:22 -07:00
return EINA_TRUE;
return !fid->get_return_no_unused;
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
case EOLIAN_PROP_GET:
if ((fid->type != EOLIAN_PROP_GET) && (fid->type != EOLIAN_PROPERTY))
eolian: rename @warn_unused and its associated API @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
2019-05-26 08:41:22 -07:00
return EINA_TRUE;
return !fid->get_return_no_unused;
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
case EOLIAN_PROP_SET:
if ((fid->type != EOLIAN_PROP_SET) && (fid->type != EOLIAN_PROPERTY))
eolian: rename @warn_unused and its associated API @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
2019-05-26 08:41:22 -07:00
return EINA_TRUE;
return !fid->set_return_no_unused;
eolian: strict function type input checks in APIs Strictness of various Eolian APIs has been enhanced, for example eolian_class_function_get_by_name now won't return anything if you request an EOLIAN_PROPERTY and the found func is just an EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD explicitly. The purpose of this is to reduce potential bugs and fix ambiguous behavior. Thanks to use of EINA_SAFETY, appropriate errors should be printed into terminal when an API is used incorrectly.
2017-01-12 07:56:49 -08:00
default:
eolian: rename @warn_unused and its associated API @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
2019-05-26 08:41:22 -07:00
return EINA_TRUE;
eolian: support @ref on returns This adds basic support for @ref on return types.
2016-06-07 06:59:36 -07:00
}
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Bool
eolian: add API to expose the new @move and @by_ref tags
2019-08-30 08:04:44 -07:00
eolian_function_return_is_by_ref(const Eolian_Function *fid,
Eolian_Function_Type ftype)
{
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, EINA_FALSE);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_UNRESOLVED, EINA_FALSE);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_PROPERTY, EINA_FALSE);
switch (ftype)
{
case EOLIAN_METHOD:
eolian: add support for function pointers in utility APIs
2019-09-03 06:03:44 -07:00
case EOLIAN_FUNCTION_POINTER:
if (fid->type != ftype)
eolian: add API to expose the new @move and @by_ref tags
2019-08-30 08:04:44 -07:00
return EINA_FALSE;
return fid->get_return_by_ref;
case EOLIAN_PROP_GET:
if ((fid->type != EOLIAN_PROP_GET) && (fid->type != EOLIAN_PROPERTY))
return EINA_FALSE;
eolian: fix typos in function_return_is_by_ref
2019-09-03 06:02:00 -07:00
return fid->get_return_by_ref;
eolian: add API to expose the new @move and @by_ref tags
2019-08-30 08:04:44 -07:00
case EOLIAN_PROP_SET:
if ((fid->type != EOLIAN_PROP_SET) && (fid->type != EOLIAN_PROPERTY))
return EINA_FALSE;
eolian: fix typos in function_return_is_by_ref
2019-09-03 06:02:00 -07:00
return fid->set_return_by_ref;
eolian: add API to expose the new @move and @by_ref tags
2019-08-30 08:04:44 -07:00
default:
return EINA_FALSE;
}
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Bool
eolian: add API to expose the new @move and @by_ref tags
2019-08-30 08:04:44 -07:00
eolian_function_return_is_move(const Eolian_Function *fid,
Eolian_Function_Type ftype)
{
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, EINA_FALSE);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_UNRESOLVED, EINA_FALSE);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_PROPERTY, EINA_FALSE);
switch (ftype)
{
case EOLIAN_METHOD:
eolian: add support for function pointers in utility APIs
2019-09-03 06:03:44 -07:00
case EOLIAN_FUNCTION_POINTER:
if (fid->type != ftype)
eolian: add API to expose the new @move and @by_ref tags
2019-08-30 08:04:44 -07:00
return EINA_FALSE;
return fid->get_return_move;
case EOLIAN_PROP_GET:
if ((fid->type != EOLIAN_PROP_GET) && (fid->type != EOLIAN_PROPERTY))
return EINA_FALSE;
eolian: move all tests to use the new @move syntax and API
2019-09-02 06:23:21 -07:00
return fid->get_return_move;
eolian: add API to expose the new @move and @by_ref tags
2019-08-30 08:04:44 -07:00
case EOLIAN_PROP_SET:
if ((fid->type != EOLIAN_PROP_SET) && (fid->type != EOLIAN_PROPERTY))
return EINA_FALSE;
eolian: move all tests to use the new @move syntax and API
2019-09-02 06:23:21 -07:00
return fid->set_return_move;
eolian: add API to expose the new @move and @by_ref tags
2019-08-30 08:04:44 -07:00
default:
return EINA_FALSE;
}
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Stringshare *
eolian: add APIs to get full C types of parameters/returns/fields These are needed because the type itself does not carry all the information it needs to carry (particularly by_ref).
2019-09-04 06:56:32 -07:00
eolian_function_return_c_type_get(const Eolian_Function *fid,
Eolian_Function_Type ftype)
{
eolian: return NULL instead of EINA_FALSE on safety checks
2019-09-19 07:04:56 -07:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, NULL);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_UNRESOLVED, NULL);
EINA_SAFETY_ON_FALSE_RETURN_VAL(ftype != EOLIAN_PROPERTY, NULL);
eolian: add APIs to get full C types of parameters/returns/fields These are needed because the type itself does not carry all the information it needs to carry (particularly by_ref).
2019-09-04 06:56:32 -07:00
const Eolian_Type *tp = NULL;
Eina_Bool by_ref = EINA_FALSE;
switch (ftype)
{
case EOLIAN_METHOD:
case EOLIAN_FUNCTION_POINTER:
if (fid->type != ftype)
return NULL;
tp = fid->get_ret_type;
by_ref = fid->get_return_by_ref;
break;
case EOLIAN_PROP_GET:
if ((fid->type != EOLIAN_PROP_GET) && (fid->type != EOLIAN_PROPERTY))
return NULL;
tp = fid->get_ret_type;
by_ref = fid->get_return_by_ref;
break;
case EOLIAN_PROP_SET:
if ((fid->type != EOLIAN_PROP_SET) && (fid->type != EOLIAN_PROPERTY))
return NULL;
tp = fid->set_ret_type;
by_ref = fid->set_return_by_ref;
break;
default:
return NULL;
}
Eina_Strbuf *buf = eina_strbuf_new();
database_type_to_str(tp, buf, NULL, EOLIAN_C_TYPE_RETURN, by_ref);
Eina_Stringshare *ret = eina_stringshare_add(eina_strbuf_string_get(buf));
eina_strbuf_free(buf);
return ret;
}
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API Eina_Bool
eolian: separate database API and internals into different source files
2014-07-10 05:13:46 -07:00
eolian_function_object_is_const(const Eolian_Function *fid)
{
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, EINA_FALSE);
return fid->obj_is_const;
}
eolian: add eolian_function_is_c_only This function allows us to mark functions that are not bindable. Also remove some obsolete code.
2014-12-03 06:59:24 -08:00
eolian: Rename EAPI macro to EOLIAN_API in Eolian library Summary: Patch 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 EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: vtorri, woohyun, jptiz, lucas Reviewed By: vtorri Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12196
2020-11-25 06:39:05 -08:00
EOLIAN_API const Eolian_Class *
Eolian: add API to return the class from a function. @feature
2015-03-16 08:04:44 -07:00
eolian_function_class_get(const Eolian_Function *fid)
{
Eolian: Fix clang warnings Return proper type (NULL, not bool)
2015-04-21 02:41:48 -07:00
EINA_SAFETY_ON_NULL_RETURN_VAL(fid, NULL);
Eolian: add API to return the class from a function. @feature
2015-03-16 08:04:44 -07:00
return fid->klass;
}