This is necessary because inheritance trees need to be validated
individually for proper name conflict checks. It also prevents
eina_hash_add related errors.
This is much like 'import' but doesn't add the imported file into
the dependency list for the current file. This is to enable doc
reference validation to remain functional without needlessly
introducing file dependencies just to satisfy it.
The issue was that standalone-parsed files (outside of dependencies
of some other unit) were not being included in that dependency tree
(obviously) which resulted in their own dependency tree being
excluded from merging, causing the database hashes to lack the
necessary elements.
To fix this, I trigger merging of the "standalone" dependency trees
separately, by calling _merge_units from defer parsing cb.
Doc refs no longer introduce new dependencies into files. Instead,
they're parsed globally, and any doc ref lookup is also made
globally. This allows unit based dependencies to correspond more
to what files actually really need at compile time/runtime, with
docs being irrelevant to that; it also simplifies the API.
The doc resolution API now takes Eolian_State instead of
Eolian_Unit, too.
This is cleaner than adding into a hash manually. Additionally, it
is now possible to request that the file be parsed not as a dep,
but rather standalone, which will be useful later.
Eolian doc objects now bundle debug information necessary to
provide correct line/column numbers. It is not possible to get
this information cirectly from the text, as it's reformatted and
contains no extra whitespace or newlines beyond paragraph
separators.
Fixes T6701.
Previously, when an error happened in Eolian, the state was left
in a presumably unusable and inconsistent condition. This work
aims to change that, as all changes are committed into a staging
area before being validated and merged back into main state.
This is not yet complete, as units and by-file lookups are not
currently involved in the rollback. This will change in the
subsequent commits.
@feature
Unlike panic, this will be used to handle regular errors
such as parse errors. There will be no jumps and you
will be able to pass in a pointer to get the error
data into some local memory. That way you will be
able to override printing error messages.
As nearly every Eolian handle is backed by an Eolian_Object,
this information is now publicly exposed and has an API. This
opens up an array of new possibilities for tooling, as you
can now externally query file names, line numbers etc.,
as well as cast arbitrary handles to Eolian_Object pointers
and back.
This will be expanded later and it will replace the Declaration
system, as it's cleaner, better integrated and more versatile.
@feature
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.
This change finally introduces deferred parsing of inherits to
Eolian, after a long time and many iterations. That means instead
of parsing inherits directly as part of the main file's parse pass,
they're pushed into a queue and parsed later. The validation engine
was modified to properly fill in the remaining info afterwards.
This may introduce breakages but I haven't noticed any. It also
properly unlocks cyclic dependency support in Eolian.
Additionally, this also introduces checks for duplicates in class
inherits (class Foo(Bar, Bar) is no longer possible) and it adds
stricter name checks, so you can no longer have a class Foo.Bar
and refer to it as Foo_Bar in implements. This was actually never
meant to be supported, but the check was previously broken.
@feature
For one, the hash has to be populated once per inheritance tree
and the skipping on already-validated funcs was interfering with
that as the function might have been validated in another
inheritance tree already.
Also, if a class appeared multiple times in an inheritance tree,
as is common with e.g. Efl.Object, it would get added into the
hash the first time and then checked against the second time,
which would result in a strange error message about the
function being redefined in its own class.
So now we prevent both cases from happening.
As it is no longer necessary to pass unit when evaluating exprs,
it is not necessary to pass it here either. Convert all the APIs
to the new style and update all instances in our tree.
This makes sure that duplicate method/part/etc checks are done on
every database update, removing the need for clunky toplevel
checks and improving reliability. It also sacrifices some
performance but it shouldn't be too bad (if a class is already
validated, some checks are avoided to speed things up).
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.
The check was only done on one of the two functions, resulting in some
unwanted warnings.
EOLIAN_WARN_FUNC_DUPLICATES=1 will show non-beta warnings.
EOLIAN_WARN_FUNC_DUPLICATES=2 will still show all warnings.
This disallows deeply nested pointers, you can only explicitly
ptr() on types that are strictly value types.
For a few cases where it was necessary to override this behavior,
you can use legacy(ptr(x)) as a temporary measure.
This is a "pass by reference to const" equivalent. There is no explicit pointer
and currently it's the same as ptr(const(x)) on the type. However, it is also
usable on properties.
No warnings:
export EOLIAN_WARN_FUNC_DUPLICATES=0
No beta warnings:
export EOLIAN_WARN_FUNC_DUPLICATES=1
All warnings including beta:
export EOLIAN_WARN_FUNC_DUPLICATES=2
EOLIAN_WARN_FUNC_DUPLICATES is not an API and may change in the future
as we improve the tool :)
Most of the time you need to retrieve the class from the string
anyway, so remove this relic of old Eolian and gain some small
performance benefits and extra convenience.
Subtly breaks API but everything should be updated.
These types are of questionable value and the API was not entirely
thought out - remove for now, and if a legitimate use is found
later, they may be readded (with a better API), but typically it
seems best to redesign the bad APIs around safe containers...
This is a new type representing a mutable string (no const).
Regular strings cannot be made mutable with @owned because
they might be hidden behind typedefs.
Even though ownership info belongs to params/returns/etc at syntax
level, we can still store it in the type and turn several API funcs
into one this way.
This is the new ownership system for Eolian, working on params,
returns, struct fields or events directly rather than specifying
ownership at type level. As the new system will evolve it will
gain missing features and necessary checks.
For example, aliases to ownable types are now also ownable,
which wasn't possible in the previous version, where you could
only own actual expanded ownable types.
Summary:
Summary : String buffer returned by eina_strbuf_new() is not freed in some cases
@Fix
Signed-off-by: Uma Devika <u.bodapati@samsung.com>
Reviewers: cedric, tasn, jpeg, raster, singh.amitesh
Subscribers: tanwar.umesh07, yashu21985, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5000
First steps toward explicit function pointer support in eolian.
To declare a function pointer type, use the following syntax, similar to
a regular eolian method declaration.
function FunctionName {
params {
...
}
return: Return type
}
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.
We don't need to keep this in eo files anymore because the APIs
using them are now fully in C. This also allows removal of the
event callback builtin from Eolian.
This allows us to unify retrieval of docs for both regular and
overridden funcs without having two separate APIs. It's currently
missing validation and docgen is still not adjusted properly for
it either, but at least there's this. Enables retrieval of docs
for overridden funcs by default as well.
As there is no need to have separate is_auto, is_empty and
is_pure_virtual for functions and implements (each function has
its own base implement by default) I removed the function ones.
Instead, I added a way to retrieve a function's base implement
so that you can instead do the checks on the implement even when
you only have the function.
I also moved base implement build directly into the parser instead
of the database filler. That allows for significant cleanup. I
also removed distinction of implement pointers in Eolian_Function
for get and set as implements now always contain an entire thing
so the pointer was always the same anyway.
Things should still behave more or less the same, but ordering
of generated functions has changed because ordering of implements
has changed.
Previously one API used just virtual (incorrect) and one used
virtual_pure (which just sounds weird). So unify with a single
name, pure_virtual, similar as in other lanugages.
This does not change eo file syntax yet.
Now all error/unknown/etc values returned from APIs are zero,
previously it was a mix of zeroes and minus ones. Also, some
enums that had no error/invalid value before have one now, which
allows for better distinction between what is an error and what
is an intended result.
Strictness of various Eolian APIs has been enhanced, for example
eolian_class_function_get_by_name now won't return anything if
you request an EOLIAN_PROPERTY and the found func is just an
EOLIAN_PROP_GET, and various APIs won't accept arbitrary inputs
like EOLIAN_UNRESOLVED or EOLIAN_PROPERTY now, instead you will
need to provide EOLIAN_PROP_GET, EOLIAN_PROP_SET or EOLIAN_METHOD
explicitly.
The purpose of this is to reduce potential bugs and fix ambiguous
behavior. Thanks to use of EINA_SAFETY, appropriate errors should
be printed into terminal when an API is used incorrectly.