MetaCall

Mentors: Student: Anas Magdy

FunctionMesh is a Kubernetes-native platform that automatically breaks a polyglot monolith apart into a distributed auto-scaled function mesh. Currently, making a polyglot codebase distributed requires service boundaries to be manually defined, RPC layers to be hand-coded, and routing configurations that have nothing to do with the actual problem being solved. FunctionMesh takes a program analysis approach to solve this problem by consuming the AST, call graphs, and data flow output of the MetaCall parser to automatically determine the deployment topology, group communicating functions into co-located namespaces, detect type mismatches at build time, and create the entire RPC layer for the user without any intervention. The functions are then packaged using the Builder CLI into a self-contained unit called a FunctionImage containing MetaCall core and the correct language loader, deployed as a FunctionUnit CRD onto a Kubernetes cluster, and connected using Istio Ambient Mesh for transparent routing, mutual TLS, and autoscaling independence. The output is the FunctionMesh Operator, Builder CLI, MetaCall RPC Gateway, Client Stub Generator, Istio Integration, Function Registry, Autoscaler Policy, and complete documentation with end-to-end demo.

Mentors: Student: Yug105

MetaCall currently supports Linux (GCC), Windows (MSVC), and macOS but many platforms where developers want polyglot runtime support are missing.The core layers have partial support for some platforms but no CI, no environment script integration, and no testing to verify they actually work.Follow TDD approach: set up CI first , then fix environment script + build system, then fix test failures.I will go platform by platform for implementation.All platform logic lives in metacall-environment.sh there will be no hardcoded logic in CI YAML. 8 platform targets with CI pipelines with working environment script section, verified CMake detection and build, automated testing.Fixes to metacall/plthook fork for platforms that need it.

Mentors: Student: Satvik Upadhyaya

This project aims to modernize MetaCall's rs_loader by migrating it to the latest rustc compiler internals. The current implementation relies on outdated APIs, making it incompatible with newer Rust versions. The project will focus on updating compiler integration, replacing AST-based traversal with HIR-based extraction, and adapting to changes in rustc_driver and related components. The approach includes analyzing breaking changes, incrementally migrating core modules (lib.rs, middle.rs, ast.rs), and ensuring compatibility with modern Rust toolchains. Deliverables include a fully working rs_loader compatible with the latest rustc version, improved type and function extraction using HIR, and updated documentation for maintainability.

Mentors: Student: Fahd Ashour

MetaSSR already delivers fast SSR and does well on the benchmarks, which is promising. But the dev mode, tests, and error handling still need hardening to be production‑ready. This project aims to make MetaSSR more mature and production-ready, focusing on improving the API handler (the core idea of MetaSSR, Polyglot programming via MetaCall), stabilizing and adding feature to the dev mode, expanding tests, and improving CI/reporting and documentation. If needed, the work will include changes to the MetaCall Rust port to support MetaSSR reliability & maintainability.

Mentors: Student: Nihal_Rodge_

MetaCall Core is a polyglot runtime written in C/C++ that enables seamless cross-language function calls. Like any large native codebase, it is susceptible to memory leaks and unsafe memory access patterns that are difficult to detect manually and invisible in standard CI. This project improves memory tracking and code coverage reporting across platforms through six deliverables: (1) a Valgrind memcheck CI pipeline integrated into GitHub Actions — already implemented and merged pre-GSoC; (2) systematic fixes to the ~5,579 memory leaks currently detected by CI, reduced from ~99,578 through pre-GSoC contributions (PRs #706, #723, #726); (3) an improved reflect_memory_tracker.h that records file, line, and call-site information for every allocation instead of just counting them; (4) a custom lightweight instrumentation layer using LD_PRELOAD or weak symbol overriding for environments where Valgrind is unavailable; (5) enhanced CI error visibility that surfaces sanitizer-style output for failing tests instead of silent segfaults; and (6) documentation covering the new tracker API, Valgrind output interpretation, and per-loader suppression file strategy. The end result is a MetaCall codebase where memory issues are caught automatically in CI, located precisely when they occur, and actionable for any contributor — not just those with Valgrind expertise.