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 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!"
Daniel Kolesa
Tom Hacohen
Daniel Zaoui
Kai Huuhko
Jérémy Zurcher