Fix generic struct pointer instantiation bug #105

[iryuken]

bug where generic structs referenced only via pointers (for example,
RcInner<T>* inside Rc<T>) were not being instantiated, leading to compilation errors.

The issue stemmed from the parser discarding structured type information for struct
fields and the instantiation logic failing to recurse into generic pointer types.
As a result, dependencies nested deep within generic struct definitions were not
detected or generated.

issue #105

What Changed

• The parser now preserves full structured type information for struct fields,
  ensuring generic relationships are retained.
• The instantiation logic has been enhanced to recursively generate code for
  nested generic pointer types.
• Name parsing issues related to generic pointer instantiation were fixed.

Verification

This behavior is verified by the included Rc<T> test case. When Rc<i32> is used,
the compiler now correctly instantiates RcInner_int32_t, confirming that generic
dependencies referenced only through pointers are properly detected and generated.

Files Changed

• src/parser/parser_struct.c
  Updated to capture and store structured type information for fields.

• src/parser/parser_utils.c
  Enhanced instantiation logic to handle generic pointers and fixed name parsing.

• tests/generics/test_generics_struct.zc
  Added regression test for recursive generic pointer instantiation.

[iryuken]

Regression Fixes & Improvements

While verifying the generic struct pointer fix, I identified and resolved two additional regressions:

1. derive(Eq) for Pointer Fields:
   The derive(Eq) macro was incorrectly generating deep equality checks (Vec_T__eq) for pointer fields like Vec<T>*, causing compilation errors. I updated parser_core.c to enforce shallow pointer comparison (ptr1 == ptr2) for pointer fields, and refined parser_expr.c to prevent the parser from rewriting == to .eq() calls unless both operands are strict value types (preserving operator overloading correctness).

2. Strict Type Checking Adjustments:
   Adjusted type compatibility rules in parser_expr.c to explicitly allow initialization of pointers with 0 (null) and to support mixed arithmetic/comparison between standard numeric types, which strict mode had inadvertently flagged.

[iryuken]

Any thoughts on adding a debug branch?

[Zuhaitz-dev]

Looks good, I am not home, but there I will check it properly and surely merge it.

Related to a debug branch, I don't think it would be a bad idea. What I do think is that we should have an experimental branch or similar.

The language is still green, but having something like this would be useful already.

[Zuhaitz-dev]

Looks good to me