This finally enables looking up things from the current unit
rather than from a backing storage in the Eolian state. This
also means that the benefits of having a unit system will
finally be visible.
This makes sure variables are stored as well as types within their
respective units. Also, declarations are now refcounted just like
any other Eolian object.
Eolian now properly merges all unit hashes (e.g. unit A has
children B and C, hashes of B and C are merged into A's hashes
in order to be able to look up B and C's contents via A) and
maintains a (potentially cyclic) children graph.
Not everything is yet added into all hashes, but at least the
building blocks are there.
Units now form an actual tree stored in their own hash. This will
later replace all global state of Eolian, by introducing a master
unit that you will pass around.
Dependencies are now going to be parsed strictly after the main
file, to allow proper dependency cycle behavior in all places. For
now there is correct parsing of deferred deps but they're not
queued yet.
Units are Eolian files (eo/eot). Each unit contains information
about its class, dependencies, variables and types. This allows
for saner checking to be done.
New API function eolian_doc_token_ref_get will resolve the kind of
reference in the given token and extract the necessary data you
might need for further use, for example class and function for
methods, or struct and field for struct field. It also supports
event references that will be added into Eolian later.
EFL will be switched to the new resolver (by changing the validator
code) during the next step.
This provides an API to tokenize Eolian docstrings. It does not
yet switch the rest of the infra to it, but it does have tests.
It doesn't verify correctness of references, as that's Eolian's
job. Therefore it's also your job to provide it with strings that
do not contain invalid references. Lua bindings are to come and
a complete switch will be done later.
@feature
Because of this the cyclic check would occasionally have false positives.
By moving deferred eo parsing to the end of the whole parse process, it
can no longer affect the cyclic checker.
@fix
This allows generators to silence type errors in validation in order
to reduce duplicate error messages when generating multiple files.
Also adjusted the C generator to only emit type errors when generating
Eo header files.
@feature
This doesn't quite work yet as path sanitization needs to be done for it to
work correctly. For now this code path is disabled and will be enabled once
all paths are correctly sanitized.
Sorry for last minute new API, but this one is necessary to implement
proper verification of references in docs, which I would like to have
in 1.15. It allows you to retrieve any kind of declaration by full
namespace, so that you can check for an existence of an Eolian decl,
rather than checking every type individually.
@feature
This is kind of ugly, but I didn't see a better way to do it without turning
this into a much more complicated parser. So this will have to do unless we
find something else to add, in which case a new doc parser will be required.
@feature
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
Eo files will now fail to compile if a cycle is detected.
This required some temporary changes in existing eo files
(we had 2 cycles) for which I added a FIXME (they do not
affect C generation).
@feature
If the class is not found, we retrieve its full path if it has already
been scanned.
This patch is needed by Espion so Eolian can find the full path of a
class by its name. Espion has no way to determine it by itself.
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.
Daniel Kolesa
Jean-Philippe Andre
Daniel Zaoui
Daniel Kolesa
Mike Blumenkrantz
Savio Sena