This commit adds new Eolian API and proper parsing support for struct types.
Structs can be named (allowed in global context, like typedefs, and in typedefs)
and unnamed (allowed as fields of other structs). This extends the existing type
API to support structs. This is incomplete for now - I still gotta add a way to
query global structs besides other things.
@feature
This new API supports function pointer types, multiple type subtypes, const attribute without parsing
the name string, own attribute for any partial type and more. This commit also updates the C and C++
generators so that they compile and generate correct code.
@feature
.eot files are similar to .eo, but they can't contain classes; all .eot files found in include paths
are parsed and information is added into the database. They're there for typedefs and eventually also
enums, structs and constants.
@feature
This handwritten lexer/parser is more strict and cleaner than the previous Ragel based one,
as well as faster and doesn't leak memory (or shouldn't). It's a recursive descent style
parser with separate lexer part (unlike the previous effort) which is run at the same
stage as the parser (so it doesn't pre-lex).
@feature
If a class (e.g Evas_Object) is expected as a base class but is not
present in the existing expected file (e.g evas_object.eo), it will not
fail.
This patch fixes it by checking the existence of the class into the
database after the parsing of the file.
@fix
The function eolian_implement_information_get was returning strings for
the class and the function. It was written in this way at the beginning
because it was not needed to verify the correctness of the class and
the function.
Now that we have the namespace feature, this function must check it,
meaning that the class and the function are now known.
So we can return them instead of returning the strings.
The generators had to find the class from the classname. It is no more
needed.
The C++ generator has been adapted to this new API.
On Windows, '\' are used to separate the names of a path. It was not
supported.
This patch fixes that. Thanks to Vincent Torri for catching it (and good
luck in Windows ;-))
Until now, the functions giving access to class information were taking
the class name as parameter.
Except the fact that we needed to search into a hash table for the internal
class structure, no flexibility is possible.
This change consists in modifying most of the APIs using the class name
with a new Eolian_Class type and adapt the code of the C and C++
generators accordingly.
It includes parser updates, database fill and tests on basic and complex
types.
One can define types in this way:
type Evas_Coord: int; /* Simple type definition */
type List_Objects: Eina_List * <Eo *>;
@feature
If classes A and B are stored in a same file, when A inherits from B,
and A needs to be generated, the generator, even if B is parsed, will
not search the class in the database but will look for some b.eo.
This patch fixes that issue by checking the existence of the classes
into the database before looking for a corresponding file.
The type of the virtual functions implemented in a class was let unresolved
and led to inconsistency when working with them.
In fact, the type can be resolved easily after all the classes that the
specific class inherits from are parsed and stored in the database.
Fix T1228
Before this change, all the .eo files of the directories given with -I
option were parsed. Most of this information was not necessary at all,
since only the classes belonging to the inheritance of the class given
as parameter were needed.
Now, during the parsing of the given class, the inherits classes are
searched and parsed.
A condition is needed to make it work well. To find a filename for a
class, we consider the lowercase of the class name as the filename we
have to parse.
e.g, Elm_Button -> elm_button -> elm_button.eo
It considerably reduces the generation time.
A fix in the tests was needed.
This patch adds support for protected functions.
In the .eo file, the scope (public by default) has to be added before
the function name e.g:
protected foo ...
To access the protected APIs, #define (CLASS)_PROTECTED is needed e.g:
#define ELM_BUTTON_PROTECTED
For get properties, if only one parameter is given, the generator sets this one as return type.
There are cases where this parameter must stay a parameter (legacy API).
For example, elm_thumb_compress_get must be like:
void elm_thumb_compress_get(const Eo *obj, int *compress).
Eolian was generating the function as:
int elm_thumb_compress_get(const Eo *obj);
By setting "return void;" in the .eo file, you force the function to
return void.
When a property needs be defined as virtual pure, its type could not be
given.
It means that, even it was explicit that e.g only the get property if
virtual pure, both (set and get) were considered as virtual pure.
@fix
Now, it is possible to assign a default return value for a
method/property.
It will be used in case the function invocation makes issues, e.g eo_do
failing to find the function...
This tag indicates that the ownership of the parameter/return
value changes.
It is needed by generators (C++/LUA...) to determine if it has to be
freed or not, if it can be used as is or need to be copied...
You can add in the .eo file the eo_prefix:... and data:... in case
you want to override respectively the Eo prefix and the data type.
If "data: null" is used, no data type will be added.
- Added Doxygen description to parameters and return
- Added default description for parameters
- Return type needs to be after all the other parameters
- Better handling of stars for pointers: try to figure if a space is
needed between the type and the variable (e.g int *a / int a)
The definition of EAPI was missing in Eolian.h.
Spank on you, Tom! I expect you to be perfect and to tell me those
things before I push all the stuff ;-)
Imported by Tom, from the eolian repo which was written by:
Daniel Zaoui <daniel.zaoui@samsung.com>
Yakov Goldberg <yakov.g@samsung.com>
Yossi Kantor <yossi.kantor@samsung.com>
Savio Sena <savio@expertisesolutions.com.br>
Jérémy Zurcher <jeremy@asynk.ch>
Signed-off-by: Tom Hacohen <tom@stosb.com>
Daniel Zaoui
Daniel Kolesa
Tom Hacohen
Jérémy Zurcher
Yossi Kantor