summaryrefslogtreecommitdiff
path: root/src/lib/eolian (follow)
AgeCommit message (Collapse)Author
2019-07-17eolian: add builtin binbuf and event typesDaniel Kolesa
Binbuf is like strbuf and allows not using the Eina opaque wrapper now, which will remove some ptr(). And event translates to Efl.Event because otherwise there would be no way to get rid of void_ptr.
2019-07-08eolian: fix leak in eolian_state_file_path_parseMike Blumenkrantz
Summary: this fixes a trivial leak where a string is leaked at the end of the function. it is not significant, but it still appears in leak detections. Reviewers: q66 Reviewed By: q66 Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D9124
2019-07-08eolian: remove API to get freefunc of typeDaniel Kolesa
This is not supported anymore. For now, the syntax is kept around because of broken C++ tests, but afterwards it will also be removed.
2019-07-08eolian: remove builtin freefuncsDaniel Kolesa
For now this does not alter API behavior, so freefuncs are still transitive to aliases etc., this will get removed later.
2019-06-26eolian: allow value types in view containers (iterators etc.)Daniel Kolesa
This restricts disallowing value types to containers that can own them. It also disallows usage of @owned on those view-only containers, as that makes no sense.
2019-06-24eolian: add library support for declaring and using errorsDaniel Kolesa
You can now declare errors like this: error Foo = "message"; [[documentation]] Then you can use them as types like this: foo { return: error(Error1, Error2, ...); } They have a separate type category and storage. They are checked for redefinitions the same as anything else though. This does not add any generator support nor it adds any advanced checking. Ref T6890
2019-05-30eolian: use c_name when building complex C symbol namesDaniel Kolesa
2019-05-30eolian: allow complete symbol renaming for CDaniel Kolesa
This adds a new unified syntax for giving declarations C names. Classes: class @c_name(Foo) Foo ... Types: type @c_name(Foo) Foo: Bar ... Structs: struct @c_name(Foo) Foo ... and so on. Type instances properly inherit those. This also cleans up some other parts of the source code. Fixes T6716.
2019-05-29eolian: fix unit version checkDaniel Kolesa
2019-05-28eolian: allow parts named like methodsXavi Artigas
Summary: The C# bindings turn parts into class properties, so part names cannot clash with method names. However, a "Part" prefix has been recently added, just like it was done for events, and therefore this eolian restriction can be lifted. With this patch part name clashes are only checked among parts, just like it is done for events. Relates to D8582 Test Plan: Everything still builds, because we have no part-method name clashes in the tree, but now they are possible. Reviewers: q66, SanghyeonLee Reviewed By: q66 Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D9031
2019-05-26eolian: add runtime API to get file format versionDaniel Kolesa
This is useful for FFI based bindings (like the Lua or Python ones) and so on.
2019-05-26eolian: prevent parsing when eo file version is too newDaniel Kolesa
2019-05-26eolian: add API to query unit versionDaniel Kolesa
2019-05-26eolian: initial versioning implementationDaniel Kolesa
This implements initial support for specifying unit versions. The default version is 1, specifying the basic feature level. If you want to specify another version, you need to specify something like `#version 2` at the beginning of the .eo or .eot file; the version number must be higher than 0 and lower than USHRT_MAX (typically 65536). The beginning of the file is now called the "header section"; other things may be added into the header section later. Version cannot be specified twice, and it cannot be specified once other contents (like types or class definition) appear. Comments do not count as other contents, so those are fine to appear before #version. @feature
2019-05-26eolian: rename @warn_unused and its associated APIDaniel Kolesa
@warn_unused in syntax is now called @no_unused - this is because "warning about unused" is a C thing (or rather, an extension to C) and various languages might want to use stricter behavior for this. Its associated API does the reverse now - it lets you query whether being unused is allowed at all. This is to match future behavior of Eolian (once it supports versioning) that will likely reverse it. @feature
2019-05-26eolian: remove param @nonullDaniel Kolesa
This has been deprecated for a while and is not strictly necessary - as a part of an effort to stabilize Eolian, remove this. Eolian will eventually gain support for versioning and use a reversed behavior (i.e. no NULL by default), but the API it wlll use for that will be very different. Features can always be added, it's much harder to drop them. @feature
2019-05-21eolian: remove @nullable keywordDaniel Kolesa
This was an experiment that never properly took off and was never used by any generator. Its use was highly variable, so it could not be relied upon. We will still want to reverse the current behavior eventually (no null by default), but that will be done with eo file versioning in the future. @feature
2019-05-16eolian: rename eolian_event_c_name_getDaniel Kolesa
This is for consistency with the new eolian_class_c_macro_get as well as for better clarity, as c_name_get is already provided by Object and refers to something else.
2019-05-16eolian: rename eolian_typedecl_enum_field_c_name_getDaniel Kolesa
This is to allow for better object oriented APIs, as the `c_name` field would be inherited from Object. This also makes it more clear in C.
2019-05-16eolian: add API to retrieve the C name of an objectDaniel Kolesa
This is to prepare for type/class renaming support. This adds the necessary API to retrieve C-specific names. Other refactoring is necessary elsewhere for now. This also renames the old API eolian_class_c_name_get to eolian_class_c_macro_get to avoid conflict as well as clarify the intention.
2019-05-09eolian: move from eo_prefix to c_prefixDaniel Kolesa
2019-05-06eolian: fail on scan file conflictDaniel Kolesa
If two files of the same name are found in the include paths, the scan should fail.
2019-05-05eolian: add support for marking and checking parts as betaDaniel Kolesa
Fixes T7837.
2019-05-03eolian: refactor parsing API and path handlingDaniel Kolesa
This splits the eolian_file_parse API into two, one for parsing files already present in the database (always by filename) and one for parsing paths. It fixes several bugs/leaks on the way (incorrect use of stringshare etc.) as well as adds checking for whether there are no conflicting filenames at scan time, for free. That means it is now no longer possible to scan two paths which have an eo or eot file of the same name in them. It should also be faster now. It also fixes T7820. @fix
2019-04-24eo_parser: fix unreachable codeTaehyub Kim
Summary: fix unreachable code for kw_enum case in parse_unit function Reviewers: q66, Jaehyun_Cho, woohyun Reviewed By: q66 Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8696
2019-04-24eolian: remove unreachable code.Hermet Park
2019-04-02docs: Fix common misspellings in H filesXavi Artigas
Fixed all appearances of words from this list in H files: https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines
2019-03-21eolian: assume requires section is legitimate dependenciesDaniel Kolesa
Previously these were not considered, which resulted in false positive warnings.
2019-03-21eolian: disallow @owned on eventsDaniel Kolesa
This is never used anywhere and it does not make sense with the new type rules for events.
2019-03-21eolian: add event type call convention checks for non-beta classesDaniel Kolesa
2019-03-21eolian: enable event redef checking by defaultMarcel Hollerbach
Reviewed-by: Daniel Kolesa <daniel@octaforge.org> Differential Revision: https://phab.enlightenment.org/D8425
2019-03-11eolian: enable checking of beta/stable contexts in all classesDaniel Kolesa
Summary: This enables all the checks unconditionally, without ignoring classes that don't have an Efl namespace. This required a lot of beta marking to make it build. It most likely doesn't mark types correctly, as that is not fully enabled yet. Reviewers: zmike, cedric, segfaultxavi, bu5hm4n Reviewed By: segfaultxavi Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8266
2019-03-09eolian: drop env var checking that is unneccessaryMarcel Hollerbach
Summary: This now does work, and we can enable the full checks Reviewers: segfaultxavi, cedric, q66, zmike Reviewed By: q66 Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8276
2019-03-08eolian: remove unused variablesDaniel Kolesa
2019-03-08eolian: remove legacy handling API and most of generationDaniel Kolesa
Summary: This removes all Eolian API that deals with handling of legacy code. It also removes the code using it in the generator as well as bindings, but for now keeps generation of .eo.legacy.h types, as there are still instances in our codebase where things are otherwise broken. We can remove the rest once that is resolved. Reviewers: zmike, cedric Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8255
2019-03-08eolian: add support for marking type declarations betaDaniel Kolesa
Summary: This also simplifies the beta checking API by unifying it under objects (makes much more sense that way) and reworks the validator to have betaness support within its context state, allowing checks to be done easily in any place. The betaness checks are disabled for types for the time being, because otherwise there are too many errors (types are assumed to be stable as they are not tagged beta, but they reference beta classes all over the place). Set EOLIAN_TYPEDECL_BETA_WARN to 1 in your environment to force enable the checks. Reviewers: zmike, bu5hm4n, stefan_schmidt, lauromoura, cedric Reviewed By: zmike Subscribers: #reviewers, #committers Tags: #efl, #eolian Differential Revision: https://phab.enlightenment.org/D8102
2019-02-28eolian: remove support for inlist/inarrayDaniel Kolesa
This feature was kind of ill-conceived and never worked properly. Since there isn't enough time to make it work right at this point and there are no users of it in the API, remove it for now. It might get added in the next release cycle, in a proper form. @feature
2019-02-28eolian: Fix struct database registration.Lauro Moura
Summary: It was mistankely swapping regular and inlist structs when registering after parsing, causing functions like eolian_state_structs_by_file_get to return wrong data, breaking C# bindings. Also added a simple test. Reviewers: q66, bu5hm4n, zmike, cedric, felipealmeida, segfaultxavi Reviewed By: segfaultxavi Subscribers: segfaultxavi, cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D8047
2019-02-28eolian: properly skip the struct keyword in inlist structsDaniel Kolesa
This was missed as a part of an incorrect merge.
2019-02-28eolian: add support for inlist structsDaniel Kolesa
This adds support for inlist structs, a special type of struct that can only be used with inlists. This differs from regular structs in a couple ways: 1) They are stored separately. Just like structs, enums, aliases have their own storage, so do inlist structs. 2) They can't be @extern, nor they can be opaque. 3) They are their own type of typedecl. 4) When they contain only one field, this field must be a value type always, cannot be a pointer. Like regular structs, they can have arbitrary fields, and they can have a pre-set free function via @free(). In C, the inlist structs will be generated exactly like ordinary ones, except they will have EINA_INLIST before the first field. Other binding generators can deal with them as they wish, for example to provide high level interfaces to them. This does not yet do the plumbing necessary to hook these into the type system, nor it adds generator support. @feature
2019-02-25eolian: validate betanessMarcel Hollerbach
Summary: if there is a none beta class, then this class should not depend on beta classes in parameters / event types / return types, parent inherits. This adds this validation, so we can start to slowly to unbeta more and more classes. Reviewers: q66, zmike, cedric, segfaultxavi Reviewed By: q66 Subscribers: #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D7999
2019-02-22eolian: introduce typed slice typesDaniel Kolesa
Summary: This adds two new complex types, slice<T> and rw_slice<T>. This is necessary to make the type useful to bindings, as Eina_Slice on its own says nothing about what it's carrying and that prevents useful code from being generated outside of C. @feature Reviewers: bu5hm4n, segfaultxavi, lauromoura, cedric Reviewed By: cedric Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D7980
2019-02-17eolian: disallow freefuncs on typedefsDaniel Kolesa
Now the only kind of typedecl that is allowed a freefunc is a struct. This simplifies the overall logic and makes freefuncs a bit more predictable.
2019-02-17eolian: restrict usage of ptr() to directly used typesDaniel Kolesa
That means, it can only now be used on parameters and struct fields, never aliased within typedefs. This simplifies the logic so that we don't have ptr metadata buried several layers deep.
2019-02-13eolian: allow tagging complete classes as BETAXavi Artigas
Summary: This allows using the @beta tag in classes, like this: class @beta Efl.Foo extends Efl.Bar { ... } This will surround the class definition in the .eo.h file with an EFL_BETA_API_SUPPORT #define, equivalent to tag every method and event with @beta. Test Plan: Nothing changes since no class uses this tag yet Reviewers: q66, bu5hm4n, zmike Reviewed By: q66 Subscribers: cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D7933
2019-01-25eolian: clear the unimplemented implement set for each treeDaniel Kolesa
We keep a hash tracking implements that were already errored on so that we don't print some errors multiple times. The problem is that it wasn't getting cleared when switching to a new inheritance tree so errors from an interface implemented in multiple distinct inheritance trees would only get printed once.
2019-01-23eolian: check old impl status before actually trying to extend itDaniel Kolesa
Since _extend_impl always marks the impl at least IMPL_STATUS_NONE, we need to retrieve the original status before calling into it, or it will get overwritten and will inadvertently disable some of the checks.
2019-01-23eolian: get rid of false positives about unimplemented methodsDaniel Kolesa
We worked under the assumption that when inheriting callables from a regular class, it's good enough to just set those as fully implemented, because the underlying class is already checked. This assumption is wrong, as the callables may contain multiple implements pointing at the same function (consider when a regular class implements just the get part of a property but some underlying class implements it whole) - the old logic would result in just the first reached implement (possibly incomplete) being added into callables of the inheriting class, which results in false positives. Consider this example: class A has a fully implemented property foo class B inherits from A and partially implements foo abstract C inherits from B class D inherits from C abstract C would go over B's implements, encounter the first partial implementation of foo, adding it into its own callables and marking it as fully implemented (because it came from an already checked regular class B), which would result in the other implement being skipped. So make no assumptions and use the same logic for all class types. Of course, this brings in another problem: some errors would now get printed twice, because if you have a class A which has funcs that are unimplemented and class B inheriting from it, errors would get printed for A but also for B, which would include A's errors. To battle that, introduce a "global" (well, local to the entry point of the validator) hash tracking which implements have already been errored on; and skip those appropriately.
2019-01-23eolian: refactor validator error loggingDaniel Kolesa
It hasn't been necessary to keep these temporary buffers around for quite a while, nobody just got around to remove them. Eolian has a good formattable error logging system in its core now. Also, use same erroring style on parts as on functions, i.e. batch-print all the conflicts at once.
2019-01-23eolian: inherit composite lists and allow in abstracts/mixinsDaniel Kolesa
There isn't any more logic necessary because checks are still only done on regular classes; we just need to make sure that composite lists from its inheritance tree are accounted for.