Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cpp] Gencpp Rework Mk II #11819

Open
wants to merge 89 commits into
base: development
Choose a base branch
from

Conversation

Aidan63
Copy link
Contributor

@Aidan63 Aidan63 commented Nov 11, 2024

This is a follow up to my previous cpp generator rework and is what I was aiming for in the first place.

Class and interface generation (as well as native and managed variants) was contained in one big function with a sprawling set of if statements to generate code based on those 4 types. Incorrect branches being taken has been the root of several bugs and the code in general is very unweildy and hard to extend.
When module level functions came out I had a go at extending the generator to output these as namespace level functions / variables but gave up as adding an extra variant was too much to deal with.

So now the cpp generate splits types into one of 5 categories, native class, managed class, native interface, managed interface. or enums. There are now dedicated generator functions for the header and implementation code of these 5 types which is mostly stitching together calls to shared functions with very little branching involved.

The fields for the class and interface types are also split up to make the generators work easier. tclass_fields are divided up into variables (physical), properties (non physical), functions, and dynamic functions. This means that areas such as generating mark and visit functions only need to iterate over the variables which makes the code much easier to follow. Previously it was iterating over all fields and needing to filter out dynamic functions, non physical fields, etc.

This division works really well and there is no case where parts of the generator needs to then further filter the lists which is quite satisfying. When these fields get split up we also handle various hxcpp implementation details. E.g. dynamic functions will put a variable into othe variable list, abstract functions will place a no-op function into the function list, and variables with default functions will place a dynamic function into the dynamic function list. These means a lot of the edge cases which were handled multiple times in various places in the generator are now handled once at retyping which, again, simplifies the generators code.

Some stuff such as class Ids and interface slots are now assigned during retyping which means the context is now more immutable.

There was more I was thinking of doing such as the retyped classes containg tcpp expressions and types but this has been going on for quite a while now and I think its good enough. I've manually ran the hxcpp test suite and it all passes and I've ran some of the tests with the generational GC and that still works.

@skial skial mentioned this pull request Nov 14, 2024
1 task
@Aidan63
Copy link
Contributor Author

Aidan63 commented Nov 16, 2024

This docgen segfault has been driving me up the wall.
At first I thought I may have been missing some variables in the updated code around generating mark and visit gc functions, but I don't believe this is the case. Dumping all classes and the member fields its generating mark functions to a txt file from for both current dev and lastest commit on this branches results in identical files.
It's also suspicious that this only occurs with docgen (so far, haxe and hxcpp test suites are fine) and always at the same place, if it were GC related I'd probably expect things to be a bit more unpredictable.

LLDB doesn't illuminate much

....................................................Process 223286 stopped
* thread #1, name = 'Dox-debug', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x00005555557c6b1a Dox-debug`markdown::InlineSyntax_obj::tryMatch(this=0x00007ffff78f14e8, parser=markdown::InlineParser @ 0x00007fffffffbbe8) at InlineSyntax.cpp:43:34
   40                   HX_STACKFRAME(&_hx_pos_4c3942c91df0077c_199_tryMatch)
   41   HXLINE( 200)            bool _hx_tmp;
   42   HXDLIN( 200)             ::EReg _hx_tmp1 = this->pattern;
-> 43   HXDLIN( 200)            if (_hx_tmp1->match(parser->get_currentSource())) {
   44   HXLINE( 200)                    _hx_tmp = ::hx::IsEq( this->pattern->matchedPos()->__Field(HX_("pos",94,5d,55,00),::hx::paccDynamic),0 );
   45                           }
   46  

_hx_tmp1 and parser both seem fine, no null addresses and visualising their children with LLDB all looks fine as well.

Extra annoyingly this doesn't occur on Windows, so I'm stuck using lldb to debug instead of visual studio...

@Aidan63
Copy link
Contributor Author

Aidan63 commented Nov 17, 2024

Turns out it does happen on Windows, I just forgot to change the haxe version to this branch...

Good thing is that I can now see more of whats actually erroring. Call stack on windows points to a memset call within PCRE2.

image

Now to figure out whats going on and see if this is a new issue or something thats been lurking for a while but has only now made itself visible.

@Aidan63 Aidan63 marked this pull request as draft November 18, 2024 22:18
@Aidan63
Copy link
Contributor Author

Aidan63 commented Nov 19, 2024

Figured it out, it was a GC related issue in the end.

Sub classes which contained no GC fields but did inherit from a parent which does contain GC fields was allocating itself with the container flag set to false.
The retyped classes now contain more information on the container status of a class so it will correctly allocate classes with the container flag and only override mark and visit if the current class has GC fields.

@Aidan63 Aidan63 marked this pull request as ready for review November 19, 2024 22:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant