Page MenuHomePhabricator

eolian inlist-inarray
Closed, ResolvedPublic


<Details in the subtickets>

bu5hm4n created this task.Dec 26 2018, 2:56 AM
bu5hm4n triaged this task as High priority.

Thinking twice about. is inlist really doable, inlist would mean that you have to ensure that the struct has the next and prev fields ... which is not possible (?) for extern structs ... :/

bu5hm4n moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jan 16 2019, 6:00 AM

inlists should allow any value-type, not just structs.

bu5hm4n updated the task description. (Show Details)Jan 21 2019, 5:14 AM
bu5hm4n renamed this task from eolian should not allow inlist of none-structs to eolian inlist-inarray.Jan 21 2019, 5:18 AM
q66 added a comment.EditedJan 29 2019, 11:44 AM

I added a bunch of stuff in my branch:

  1. inarray can only take value types
  2. added support for inlist structs:
inlist struct Foo {
    fld: Bar;
    another_fld: Baz;
free(inlist<Foo>, func_that_frees_foos)
  1. Removed any sort of builtin freefunc support from Eolian and moved it to generator. The reason is that the generator has to know about the containers (everything is in Eina anyway) and the builtin free funcs did only half of the work (iterative freeing still had to be done manually) and it was just not done properly for stable Eolian, so for now it's gone and it might get readded in the future.
  2. Disallowed containers in containers (e.g. list<list<T>>)
  3. Disallowed overriding free functions for most builtin types; i.e. now you can only do it for structs, inlists, mstrings and aliases to one of the 3.
  4. Reworked the C generator bits to reflect that.

It currently fails in Eolian cxx tests and probably mono tests, so those will need to get fixed before it makes it into master. There is also a concern about inarray; I added support for freeing owned fields of structs in an inarray, but it doesn't do iterative freeing for those, e.g. lists with owned contents will not get properly freed, or rather, the contents won't. Do we want to expand upon that? Or do we want to restrict Eolian somehow?

I'm also taking feedback on everything else.

q66 added a comment.Jan 30 2019, 2:37 AM

Added support for iterative freeing of fields in inarray structs, though still not sure whether to keep it.

q66 closed subtask T7649: eolian: restrict inarray<> usage as Invalid.
q66 closed subtask T7648: eolian: refactor inlist<> usage as Invalid.
q66 closed this task as Resolved.

Removed in 4b1622b5fc7c6aaafb4d70f187ec5ea797275a26

Will be implemented correctly from scratch when the next merge window opens