Explore Projects

The current implementation of cargo fix is quite slow and makes extra calls to rustc slowing down the process. A simplified architecture would also make it easier to add features to cargo fix. This project aims to create a new prototype version of cargo fix that uses cargo check instead of calling rustc directly.

This project aims to create a robust, high-performance parser combined with an easy-to-use macro system for the Teal programming language. Leveraging a bicameral macro model, the project clearly distinguishes the parsing and macro expansion phases whilst still keeping the syntax streamlined. This enables flexible, powerful compile-time code transformations while maintaining clarity and efficiency in compiler design and performance.

<p>Create a web application that integrates with an existing buildbot infrastructure to fully automatically track the performance of many aspects of Halide over time, including but not limited to compile times, code size, memory footprint (RSS and stack usage), and execution speed for both the compiler proper and the optimized pipelines. When evaluating a pull request, a clear visualization can ensure you notice whether there is any metric changed at a glance.</p>

The `offload` feature is currently working on the Rust compiler but still there's no safe and user-friendly interface. Right now, the only way to use it is via the `offload` intrinsic, which is discouraged for general use. The goal of this project is to build an ergonomic frontend around a function-like macro together with lightweight abstractions for device management, host-to-device data handling through Device<T>, and compile-time validation of device-compatible types.

Static analysis helps developers to find bugs in their code at compile-time. Shipping a static analysis tool built into the compiler, which can be enabled by just a command line argument, makes the process for developers easier than ever. GCC gained a static analysis pass with version 10 and is constantly improving since then. This project aims to implement several checkers that are already offered by the clang static analyzer in GCC's static analysis pass.

<p>This project revolves around developing a mechanism allowing individual developers to reach out to Open-source organizations and pledge a research project directly within the donut platform from submitting a proposal within the donut platform all the way through to the completion of the project.</p> <p>When a developer or a certain user wants to suggest/propose an idea to an open-source organization it mostly ends up being communicated through IRC messages or other informal ways. In most cases, their suggestions/proposals go unanswered or ignored among hundreds of messages in the IRC resulting in the original user getting frustrated.</p> <p>The issue here is that there is no clear cut procedure/pathway that a user can follow in order to propose a project to the upper echelons of an organization</p> <p>The project at its core focuses on eliminating that issue by providing the users with a built-in platform with which the users can create, edit, communicate, publish and share the proposals directly with the organization all within a single platform.</p>

<p>This project seeks to design and implement a class system for Typed Lua which will replace its current class definition style. It should feel like a cohesive component of the language, rather than a layer on top of Lua's meta-programming primitives. Because Typed Lua compiles to Lua and is designed to interact with regular Lua code, its code generator should support user-defined plug-ins for compiling Typed Lua class definitions into a specific untyped Lua class system.</p>

The goal of this project is to create a documentation generator for the Teal programming language. The generator will extract information from types and comments to produce documentation in both Markdown and HTML formats. The tool itself will be written in Teal and will utilize its compiler as the primary source of information. By the end of this project, we will extend the Teal compiler to retrieve all the necessary information for documentation generation. Additionally, we will deliver a CLI tool capable of parsing Teal code files and generating documentation in various formats.

<p>memory_order_consume gets automatically promoted to memory_order_acquire due to the difficulties faced by the compiler while tracing dependencies at the C/C++ source-code level, and because of memory_order_acquire, additional memory instructions come in which might affect the performance. This proposal is about the implementation of memory_order_consume only by marking pointers which are carrying dependencies, not the other objects. Also, there are various compiler optimizations, both at GIMPLE and RTL levels that may break the dependencies, which may not be desired by the user. So, we need to find and prevent those dependencies breaking issues in various optimizations.</p>

ENIGMA is a free, open source development environment and game engine. It supports game development in Linux, Windows and MacOS and also Android as an endpoint. In order to support these numerous platforms a good testing suite is required so that ENIGMA developers can be productive instead of worrying about their code breaking on a platform they are not familiar with. As of yet the test harness runs its numerous tests only on linux. This proposal aims to provide a win32 based port of the x11 test harness and integrate it with azure pipelines which will allow the engine to be thoroughly tested in both linux and windows.

<p>The AeroGear UnifiedPush Server is a powerful and scalable server that allows sending push notifications to different (mobile) platforms. And now it’s time to extend it and add supporting for a new WebPush protocol, which will allow to send push notifications to the web browsers, such as Google Chrome and Mozilla Firefox.<br> The project also supposes integration of AeroGear WebPush Server with UPS, which will allow to send push notifications to any device without requirement to use vendor’s push-messaging systems (Google Cloud Messaging, Mozilla Push Service).</p>

This project aims to integrate the Faust programming language with Audiokinetic's Wwise - the industry standard audio middleware in game development. Two key deliverables will be created: a faust2wwise tool for statically compiling Faust DSP code into Wwise modules, and a plugin that embeds the libfaust & LLVM JIT compiler for dynamic Faust DSP live-coding within Wwise. Drawing on experience in C++ audio programming, DSP techniques, and plugin development, a practical connection will be built that allows audio designers and programmers to use Faust's DSP capabilities directly within their Wwise workflows.

<p>Nuitka is a Python compiler written in Python. It is a seamless replacement or extension to the Python interpreter and compiles every construct that CPython does. Nuitka works by translating Python code into a C level program which can be executed in the same way as CPython using libpython and a few C files of its own. All optimizations of Nuitka are aimed at improving performance while ensuring perfect compatibility. This project ensures Nuitka’s compatibility with the top 50 PyPI packages by setting up automated testing for each package. These automated tests will serve to be very important tools for the development of Nuitka, as they will be used to assure Nuitka’s compatibility with the most used Python packages every time Nuitka receives a new update.</p>

<p>Lunatik is a kernel-level Lua interpreter version for scripting the Linux kernel. For example, it allows users to filter packets using Lua scripts. kTLS is a new socket type provided by Linux that transparently handles the encryption and decryption of TLS messages.</p> <p>ULP (Upper Layer Protocol) is a new feature merged recently in the Linux kernel which allows user-space programs to attach L7 functionalities to the in-kernel socket structure. kTLS is implemented via ULP.</p> <p>The purpose of this project is to implement a kernel level Lua hook inside the kTLS infrastructure. This way we could use Lua scripts to inspect the contents of the HTTP messages transparently inside the kernel.</p>

<p>The aim of this project is to add GCC C Extensions such as compiler attributes, vector extensions, etc. in Csmith. Run Csmith against GCC and report compiler bugs if found any.</p> <p>Following GCC C Extensions will be added during GSOC timeline -</p> <ol> <li>Function attributes</li> <li>Type attributes</li> <li>Variable attributes</li> <li>Label attributes</li> <li>Vector extensions and Transaction atomic (not a GCC C Extension)</li> </ol> <p>Base branch for the project - <a href="https://github.com/shubhamnarlawar77/csmith/tree/csmith-gcc-v2" target="_blank">https://github.com/shubhamnarlawar77/csmith/tree/csmith-gcc-v2</a></p>

This project addresses the lack of execution tests for the BPF backend in GCC. While GCC has many compile-time tests, the BPF backend, which generates eBPF code run by the Linux kernel, lacks runtime validation. The goal is to create a test tool that runs eBPF programs on a live kernel in a virtual environment (using QEMU), similar to the kernel's selftest infrastructure. The tool will load and execute BPF objects and report results, allowing us to catch regressions early. Next, this tool will be integrated into GCC's Dejagnu-based testing infrastructure, and a dedicated testsuite for the BPF target will be added to the GCC testsuite. This project will help ensure that compiler changes do not inadvertently generate eBPF code that the kernel verifier rejects.

The integration of automatic differentiation (autodiff) into the Rust compiler via Enzyme faces challenges due to ABI adjustments that alter function signatures. These transformations, while beneficial for performance, interfere with autodiff functionality, leading to incorrect differentiation. This project aims to prevent unwanted ABI adjustments for functions marked with #[rustc_autodiff], ensuring autodiff functions maintain their intended behavior without affecting other optimizations. The approach involves modifying Rust’s function ABI handling to recognize and preserve differentiation-related information. Key steps include identifying problematic transformations, encoding autodiff metadata in FnAbi, and preventing ABI changes that break autodiff. By addressing these challenges, the project will improve autodiff support in Rust, making it more reliable and consistent while preserving compiler efficiency.

<p>Google Protocol Buffers is a language-neutral serialization library. However Chapel support for Protocol Buffers has not been investigated. Nonetheless, there are a number of interoperability scenarios that would benefit from having such a feature. This feature is something that many other projects can build on - including calling Python from Chapel or creating a Chapel distributed in-memory key-value storage service.The protocol buffers compiler supports a few languages directly but also includes a plugin mechanism to generate code for other languages. These plugins can be written in the target language.</p> <p>The project involves the following:</p> <ul> <li>Create a Chapel library that works with basic Protocol Buffers functions.</li> <li>Implement a Chapel plugin for the protocol buffers compiler.</li> <li>Demonstrate this tool in an example integration using protocol buffers.</li> </ul>

One pertinent use case of the gcc-python plugin was to provide the infrastructure for cpychecker, a static analysis tool designed for CPython extension modules. The primary objective of cpychecker was to assist programmers in identifying common coding errors in their extensions, which, in turn, could lead to difficult-to-find bugs in their systems. However, the gcc-python-plugin has suffered from bitrot over the years, and as a result, cpychecker ceased functioning several GCC releases ago. The goal of this project is to port the functionalities of cpychecker to a -fanalyzer plugin, offering programmers a reliable tool for conducting static analysis of CPython extension modules once again in a more maintainable manner. The project will be divided into several logical components, such as reference count checking, format string checking, error handling checking, and verification of PyMethodDef tables. Accomplishing this task will involve building a -fanalyzer plugin and extending certain areas of the existing analyzer.

Faust is a functional programming language that enables people to express sound synthesis and audio processing algorithms concisely, efficiently, and portably. It is known for targeting a wide variety of environments: Faust code compiles to C, C++, LLVM IR and more, and for many different audio APIs and environments. In recent years, following the development of asm.js, Emscripten, Audio Worklets, and WebAssembly, the web has become an increasingly viable platform for DSP and audio programming. Prior work has enabled the generation of Audio Worklets (and older Script Processor Nodes) from Faust code. Furthermore, Faust has web-based tools such as an editor, IDE, and playground that allow people to easily try the language and hear the results without installing a compiler toolchain. I propose to improve Faust's support for the web platform by 1) updating and extending the Faust web tools and 2) building on Faust's ability to target WebAssembly in order to make Faust documentation more usable and to make it easier to find and share Faust code on the web.

Currently, the CVE-BIN-TOOL supports basic VEX triage functionality but lacks user-friendly tools for editing, validating, and managing VEX data. VEX’s JSON-based structure, while machine-readable, it is error-prone for manual human interaction, which often leads to invalid files or incomplete triage information. This project aims to bridge this gap by working on cve-bin-tool’s VEX capabilities through these three key pillars: 1. Interactive HTML Reports: Embedding JavaScript-based editing interfaces to enable offline-compatible VEX triage with real-time validation. 2. CLI Automation: Developing tools for validation, guided generation, and archival of VEX files to minimize manual effort. 3. Standardized Maintenance: Integrating the lib4vex library to unify support for CSAF, OpenVEX, and CycloneDX formats while ensuring schema compliance. By simplifying VEX workflows, the project will allow developers to manage vulnerability context effectively, reduce their errors, and align with evolving security standards.

<p>Jupyter project provides a way to perform scientific/mathematical computations with several different programming languages using the same user interface. It achieves that by distributing the processing between a front-end (Jupyter clients, like the web based Jupyter Notebook) and a back-end (Jupyter kernels, written in Python, R, Java, etc.), that communicate among themselves with standardized format messages, transmitted through ZeroMQ connection.</p> <p>Besides the ability to switch across different kernels from the same common interface, another advantage of this approach is the possibility to run the two software components on different machines, e.g., offloading the heavier backend processing to a remote server while sending commands and visualizing data from a mobile device running the frontend.</p> <p>For Scilab, there is currently a kernel that uses a compatibility layer with file access data exchange and numpy calls to communicate with clients through the Python reference implementation.</p> <p>This Google Summer of Code proposal aims to adapt or rewrite the current suboptimal solution, to make it a truly native kernel, linking ZeroMQ messages directly to Scilab API.</p>

This proposal bridges the gap between audio processing and machine learning by introducing an automatic differentiation (AD) library for the Faust programming language. This library empowers audio engineers to leverage machine learning within their familiar Faust environment. The core of the library will be pre-defined building blocks. These include Faust primitives with built-in derivative functions for common math and audio processing tasks. Additionally, there will be helper functions to simplify program construction and various loss functions specifically suited for audio processing. The proposal also explores Faust Neural Net Blocks (FNNBs), which are pre-written code modules representing specific neural network functionalities. These FNNBs will save development time, improve code maintainability, and allow audio engineers to focus on network architecture rather than low-level programming for each layer. The project deliverables will showcase the utility of the AD library in various phases. Phase I will deliver a working example of a differentiable filter or envelope in Faust. Phase II will focus on implementing a full-scale machine learning algorithm. This will be achieved through an autodiff file and a weights file. Finally, Phase III and IV will deliver an autoencoder implemented using FNNBs. By combining the AD library, FNNBs, and an architecture file specifying the training process, users can design and train complex neural network models for audio processing tasks entirely within Faust. This eliminates the need to switch between Faust and separate machine learning frameworks, while offering the benefits of automatic differentiation for efficient model training.