Fix segfault when using Generator.map with PonyCheck shrinking (#5006)

When a lambda is nested inside an object literal inside a generic
method, collect_type_params copies type parameters twice, producing
an ast_data chain of length > 1 (copy'' → copy' → original).
reify_typeparamref followed this chain only one level, so the
doubly-copied type params never matched. This caused the lambda's
apply method to not be marked as reachable during codegen, leaving
a hole in the vtable and segfaulting at runtime.

The fix follows the ast_data chain to the root (the self-referential
node set during the scope pass) for both sides of the comparison,
handling any depth of nesting.

The same single-level ast_data pattern existed in reify_reference.
While investigation showed that code path is not currently reachable
in the nested lambda scenario (TK_REFERENCE nodes are resolved by
the refer pass before any reify call encounters them), the pattern
is structurally vulnerable. Applied the same chain-following fix
defensively, guarded by a TK_TYPEPARAM check on ref_def since scope
lookup can return other node types.

Closes #4838
Closes #5005

Author: SeanTAllen

.release-notes/fix-reify-typeparamref-nested-lambdas.md

@@ -0,0 +1,15 @@
+## Fix segfault when using Generator.map with PonyCheck shrinking
+
+Using `Generator.map` to transform values from one type to another would segfault during shrinking when a property test failed. For example, this program would crash:
+
+```pony
+let gen = recover val
+  Generators.u32().map[String]({(n: U32): String^ => n.string()})
+end
+PonyCheck.for_all[String](gen, h)(
+  {(sample: String, ph: PropertyHelper) =>
+    ph.assert_true(sample.size() > 0)
+  })?
+```
+
+The underlying compiler bug affected any code where a lambda appeared inside an object literal inside a generic method and was then passed to another generic method. The lambda's `apply` method was silently omitted from the vtable, causing a segfault when called at runtime.

src/libponyc/type/reify.c

@@ -17,13 +17,19 @@ static void reify_typeparamref(ast_t** astp, ast_t* typeparam, ast_t* typearg)
   ast_t* ref_def = (ast_t*)ast_data(ast);
 
   // We can't compare ref_def and typeparam, as they could be a copy or
-  // a iftype shadowing. However, their data points back to the original
-  // typeparam definition, which can be compared.
-  ref_def = (ast_t*)ast_data(ref_def);
-  typeparam = (ast_t*)ast_data(typeparam);
-
+  // an iftype shadowing. Follow the ast_data chain to the root
+  // (self-referential node set during the scope pass) for both sides.
+  // A single-level follow is insufficient when type parameters are copied
+  // multiple times, e.g. a lambda inside an object literal inside a generic
+  // method — collect_type_params creates copies of copies, producing a chain
+  // of length > 1.
   pony_assert(ref_def != NULL);
+  while((ast_t*)ast_data(ref_def) != ref_def)
+    ref_def = (ast_t*)ast_data(ref_def);
+
   pony_assert(typeparam != NULL);
+  while((ast_t*)ast_data(typeparam) != typeparam)
+    typeparam = (ast_t*)ast_data(typeparam);
 
   if(ref_def != typeparam)
     return;
@@ -97,10 +103,22 @@ static void reify_reference(ast_t** astp, ast_t* typeparam, ast_t* typearg)
   if(ref_def == NULL)
     return;
 
-  ast_t* param_def = (ast_t*)ast_data(typeparam);
-  pony_assert(param_def != NULL);
+  // Follow the ast_data chain to the root (self-referential node set during
+  // the scope pass) for both sides of the comparison, same as
+  // reify_typeparamref. A single-level follow is insufficient when type
+  // parameters are copied multiple times by collect_type_params for nested
+  // lambdas/object literals.
+  if(ast_id(ref_def) == TK_TYPEPARAM)
+  {
+    while((ast_t*)ast_data(ref_def) != ref_def)
+      ref_def = (ast_t*)ast_data(ref_def);
+  }
 
-  if(ref_def != param_def)
+  pony_assert(typeparam != NULL);
+  while((ast_t*)ast_data(typeparam) != typeparam)
+    typeparam = (ast_t*)ast_data(typeparam);
+
+  if(ref_def != typeparam)
     return;
 
   ast_setid(ast, TK_TYPEREF);

test/full-program-tests/regression-4838/main.pony

@@ -0,0 +1,38 @@
+use "pony_check"
+use @pony_exitcode[None](code: I32)
+
+// Regression test for https://github.com/ponylang/ponyc/issues/4838
+//
+// When a lambda is nested inside an object literal inside a generic method,
+// type parameters are copied twice by collect_type_params. The compiler's
+// reify_typeparamref followed the ast_data chain only one level, failing to
+// match these doubly-copied type parameters. This caused the lambda's apply
+// method to not be marked as reachable, leaving a hole in the vtable and
+// producing a segfault at runtime.
+//
+// The bug manifests when Generator.map's internal _map_shrunken method
+// passes a lambda to Iter.map, creating a chain of nested object literals.
+// Iterating the resulting shrink iterator triggers the segfault because the
+// lambda's apply method has no vtable entry.
+
+actor Main
+  new create(env: Env) =>
+    let gen = recover val
+      Generators.u32().map[U32]({(n: U32): U32^ => n + 1})
+    end
+    let rnd = Randomness
+    try
+      // generate_and_shrink returns the mapped value and a shrink iterator.
+      // The shrink iterator is produced by _map_shrunken, which uses the
+      // nested lambda pattern that triggers the bug.
+      (let value: U32, let shrunken: Iterator[U32^]) =
+        gen.generate_and_shrink(rnd)?
+      // Iterating the shrink iterator calls the nested lambda's apply.
+      // Without the fix, this segfaults due to the missing vtable entry.
+      while shrunken.has_next() do
+        shrunken.next()?
+      end
+      @pony_exitcode(0)
+    else
+      @pony_exitcode(1)
+    end