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.
Daniel Kolesa
Tom Hacohen
Daniel Zaoui