lgtm

this was created in order to have classes that only have static methods (i.e. I guess as a crutch to be able to have free-standing functions in eo). If we still need this we can land it

this looks fine to me but better reviewed by @bu5hm4n

otherwise looks good to me, but fix the thing @zmike said

the ifdef is no good, because that changes the layout/values of the enum depending on if you're compiling with BETA_API_SUPPORT or not, which sucks from ABI perspective; you need to make it have a placeholder of some sort in the other case

the whole reason the keyword is still there is pretty much these 4 enums, nothing else in the tree uses it... i'd prefer to do away with it entirely

Hm, it displays now. Previously phab would not show it.

I think the revision is wrong, it doesn't contain the previous changes but it should because they were reverted

We should do the same thing for enums.

I implemented that already, it's behind an env var (EOLIAN_ENFORCE_SINCE)

Hm, I guess it should check it. I'll look into it and see how viable it is. If we can't change it it shouldn't be a big deal though.

?

T8491 is fixed now.

Otherwise looks good to me

yeah, i'm on it

Well, I fixed the root cause: 9ca573f40f1065cc717c0c5aabb787671bab852b

Still makes edje_cc hang, after introduction of 7f53d9158395504151e1ff3dcae715a799d913a8.

lgtm

It definitely generated title headings last time I tried... that's the reason I added the distinction in the first place.

35b2a10dd5e05e668e025697075076851acff845

This is already done differently

You shouldn't need this. A title header is already emitted by the writer itself, see writer.lua, the __ctor method. It just uses the Dokuwiki title plugin by default, if you don't have it, pass --disable-title and it will fall back to headers.

No. This would create disparity in how the API behaves depending on an arbitrary switch, which is completely unacceptable.

2946cb3c325f27d77354ac1b83b614e3a1d9e1d5

Yeah, so it was the issue then :) I suspected something with alignment/padding with the union'd definition of Eolian_Expression not playing nice with the typecast, looks like my suspicion was correct.

can you try again after the latest commit?

i'll need a better backtrace for this...

This appears to be wrong. The "default values" are only allowed for property values {} block as well as for @out parameters, Eolian will not accept them for @in parameters. I.e. those values are default fallbacks.

Please don't, I already have this mostly done with other changes and this just creates more work for me.

as @segfaultxavi said

In T8184#142189, @tasn wrote:

In T8184#142185, @q66 wrote:

@raster that's because requires is not extends, requires pretty much specifies a list of classes that are required to be in inheritance tree of the thing using the mixin; by specifying it, you tell eolian that it's guaranteed it'll be there, and the mixin can safely implement it.

Yeah, we understand what "requires" means, as in why the name is there. Though how is it different than implements? As that's exactly what's going on here?

@raster that's because requires is not extends, requires pretty much specifies a list of classes that are required to be in inheritance tree of the thing using the mixin; by specifying it, you tell eolian that it's guaranteed it'll be there, and the mixin can safely implement it.

As of afc011d8931006bd020ba5130a581580f709edcf, usage of ptr() is banned in stable API. That's bound to be good enough for now, and removing it from beta is a separate task, so closing this as resolved.

this doesn't correctly fix the eolian_type_c_type_get usage yet, which means this will behave wrong with the tag; i still see EOLIAN_C_TYPE_DEFAULT/PARAM/RETURN being passed around.

OK, I did that for now, but we'll need to figure out a proper one...

I think we've got this down, eolian properly checks and verifies this

this is now banned in stable API... removal still pending

Hm, what should be do about this? Do we want this to be thread-safe? Because the error API is not...

Closing this as the system is generally sound. Syntax changes may happen but no design alterations

Please rebase for the @class -> @static method change