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 syntax to define a parameter of a property as const is as following:
set {
data: const;
}
When no space was present between ':' and "const", a syntax error was
occurring.
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.
It includes too fixes for the complex type. If I had listened to Tasn,
I would have detected them a long time ago.
But he didn't insist enough. He just said:
"Write your tests, ?#@*&%! french!"
define scope keywords 'protected' and 'public'
disallow scope keywords as property or method name
use move_ts action to move token start after scope modifier if found
use end_property_scope and end_method_scope actions to handle it
They are not needed on normal build. Two flags have been added to
enable/disable INF and DBG.
Two warnings have been removed since they are not printing interesting
and relevant information.
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
strncmp bytes number was not correct. A problem in the generation was
occurring when the parameter is @inout, as it is considered as @in and
the type was "out ...".
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...
When a new line was added before the last } in a .eo file, the parsing
was resulting in an error. It was due to the fact that some pointer
indicating the eof was not set when the parsing was done from memory.
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)
If the first character of the description was not an alphanumeric, it was
not finalizing the parsing of the description and was not inserting it
in the database.
It was occurring when "@since" was the first word in the description of
the function.
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>