The thing in charge of freeing the structure is in charge of freeing its owned fields. If they're not marked owned, it is assumed that the struct does not own them and they will be freed somewhere else. I wonder if this behavior is what we want though. Maybe we should make them owned by default, and reverse the behavior so that you explicitly have to mark the field *not* owned in order to prevent it from being freed as a part of the structure?

Yes, we allow that. It means the struct owns the reference. If the field is not @owned, it will not be freed when freeing the structure. It is separate from owning on params; if the param is not owned, it means the caller will free it, if it is, it means the callee will free it. Either way, @owned fields will be freed by one of them.

you forgot an else

Fixed in 18ab4f2eec444bbef11605bd0e2ba057709cbb7e.

actually, i found a better way for this, so please abandon the rev

Landed the Eolian-side enforcement in 1b7129cea0d90f76a21bd6b4e40d1528141e087f.

I did however disable explicit usage of it in interfaces in 90f604327586eb8fb3f0c9e7b83816573bea820d.

I added a check to help with this in eb830d8e46ce5aae656bc7d93a4d01bac0a82e5d. Methods/properties are implicitly pure_virtual in interfaces, so the ticket is a bit misleading, and it's currently also allowed (and used) in mixins. However, pure virtual methods are treated as unimplemented by 211064113104702b2c6bd279e9e8a04ee0e8254a, so any potential cases are caught by that.

👍

Besides that one thing, looks good to me, I think.

Yes, have those two values for now, and if "lua" is selected, disable elua entirely. I will update it as necessary when luajit is removed.

my proposal involves keeping support for *only* 5.3, so a build option will be unnecessary

Also, it's not true that 5.1 is API/ABI compatible with luajit; it only applies the other way around, i.e. luajit is a superset of 5.1 functionality. While elua itself might compile with 5.1 (because it doesn't really use any C API calls beyond what 5.1 provides), it will be effectively useless because all the elua scripts rely on runtime luajit functionality (primarily the FFI)

elua only supports luajit.

Well, since it covers all the C# docs, I'll just go ahead and remove it from our own generator for the time being. The current C# code is pretty much copy-paste-parts-of-the-generator-into-separate-file-and-modify and it's kind of a pain to do changes in it as i make them in the rest of the generator, so if we want C# support later in it, might as well just write it from scratch.

The API reference is correct. The problem is that the .eo file it's referencing is not being installed, which means it works in-tree but not when in the system...

Does this mean we will not need C# support inside the eo doc generator?

@segfaultxavi as for tagging methods directly, well, eolian by design doesn't specifically enforce ordering of methods in their block, especially since generators typically work with Eolian_Implementation rather than Eolian_Function list directly; in a constructors section, we'd typically want the order of the fields to be strict, I'd assume.

this is not possible to do efficiently in the eolian library (would require revalidating classes multiple times, as well as keep a fresh hash table for each validation layer and that would likely add quite a bit of time)

That has for now optionally been done in T7365, once all the definitions are fixed, we can enable it unconditionally...

added in be7d76ece63844f1967ee12d042c920a8540ab4a

eolian in fact does have a way to do notes, just start the paragraph with "Note:", so like you did, but different case

Initial work has been merged on T7459. I believe once that is done, we can restrict things in Eolian so that only interfaces/mixins are allowed in the "implements Foo, Bar" list, but that will need some .eo file refactoring...

Initial work done in c8e0a1d2e2eaa5b8369eeb34a38b3b343788703f.
API updated in 14ce54c30321e3b78b979872427b07d9420d5c66.

A fix for this issue has been introduced in 9535eff025d7be0810e07917ea642b44104995d5. However, it cannot be enabled just yet, since we have those conflicts (like resize) in the tree so those must be fixed first...

this has been solved with the recent grouping changes, therefore closing

so that third party bindings can make use of it, obviously

yep - and we need a standard way which is not a bash script

welcome back @cedric o/

eolian_aux which is currently under review (D7245) provides this.

Not what I am getting

Also, I believe you are wrong:

IS that so? That is interesting, because a potential change of implementation (i.e. potentially behavior of Eolian itself) should trigger re-generation of eo.* files (in order to account for the new behavior), and changed headers should rebuild the rest of it. At least that's how I see it, if Meson does not do it, we potentially have another problem at hand...

Honestly, I think we should drop autotools as soon as possible.

why not? i don't see any particular disadvantage to it, and at least it allows addition of new APIs and being able to run tests on them without triggering a full EFL rebuild every time (as eolian_gen itself is most likely not going to depend on it)

I had plans for more, but I wasn't able to abstract these APIs well enough to make it into a reusable piece that makes sense. So for now there's these (they will help shorten the docgen) and more will be added gradually as I figure them out (but I won't actually focus on the library anymore once it's merged, just add new APIs as they make sense)

Perfect. We can synchronize efforts later then.

I took a break from that to work on meson, eolian_aux (which will be used to move some of the core from the docgen) and some other things, but the code is all in my personal dev repo... I will try to get a proper repository set up early next week or maybe even during this weekend. If somebody wants to help with working on the doc generator or even provide feedback on the generated output, go ahead, it would be much appreciated.