Explore Projects

<p>The Clang Static Analyzer (analyzer) can discover errors in a code by a technique called symbolic execution. Its core essentially interprets C, C++, Objective C or Objective C++ code, and at several program points allows it’s modules, or checkers to emit reports. Later, it will construct a bug report, that shows how the error can be reproduced. These steps (such as that the analyzer modeled a call to function, assumed a variable is positive, etc.) are collectively referred to as a bug path. Ideally, this contains every information needed to reproduce the error, but is minimal. However, it can contain either too little or too much information.</p> <p>In my proposed project, I indent to use static backward program slicing to enhance bug report generation. Instead of doing a fix-point algorithm on the control flow graph (CFG) though, my solution would be implemented on the abstract syntax tree (AST). This solution would only be an estimation, so I only propose to add more information to the bug reports, and research whether program slicing could be used for bug path shortening as a followup work.</p>

This proposal is based on the open LLVM project with the same title, from Tue Ly and Joseph Huber. See https://discourse.llvm.org/t/libc-gsoc-2024-half-precision-in-llvm-libc/77027. The IEEE 754 binary16 format (also known as “half precision”) has most recently gained popularity in machine learning, which often does not require higher precision, and can benefit from increased performance when using smaller data types. It has been standardized as the _Float16 type in the drafts of the C23 standard. This project aims to implement support for this new floating-point data type and the associated variants of the C library’s math functions, in LLVM’s libc. Deliverables: 1. Add support for usage of the new type in generated headers through the float16 alias on supported compilers, compiler versions, and architectures. 2. Add generic implementations of the C23 half precision basic math operations for supported architectures. 3. Add possible specialized, higher-performance implementations of the C23 half precision basic math operations for individual supported architectures using hardware instructions and compiler builtins. 4. Add generic implementations of C23 half precision higher math functions for supported architectures. (Not all higher math functions can be implemented in the amount of time we have.)

This project brings drawing tablet and touch support to Graphite and builds a modern GPU-accelerated brush engine designed for professional digital art workflows. It introduces non-destructive, resolution-independent stroke rendering with support for stylus features like pressure and tilt, enabling high-quality painting that stays sharp across zoom and resolution changes.

<p>This project aims at improvising traversal of large graphs, serialization of objects, optimizations on GPU, optimization of fast_run flag, inclusion of optimizer_excluding flag, fixing of slow optimizing phase during compilation and faster cyclic detection.</p>

In GNU Radio, the gr-fec framework implements forward error correction (FEC) through pairs of encoder/decoder deployment blocks, but there are other open-source implementations that include methods that perform better in some applications. This project will incorporate FEC methods from other open-source platforms, like AFF3CT, to improve GNU Radio's performance. Additionally, this project will develop a testbench to compare different FEC techniques and implementations using throughput and error rate.

For this project, we would design and implement an interactive mode for command-line tools built using ArgumentParser that prompts for any required arguments not given in the initial command. In the past, users would get lengthy error messages and help text when the command is incomplete. Interactive mode will reduce duplication and provide a conversational CLI which is both easier to write and easier to read.

<p>Tab completion in LLDB is a very useful function for users. However, it is needed that users press [tab] key to confirm completion. If they can confirm completion without press it, LLDB will become a more useful debugger. In addition to it, tab completion is not based on command history. Therefore, the same completion is suggested if the user presses [tab] key when the same characters are typed. If the completion function is based on history, completion is suggested depending on the situation, and LLDB will be easy to use. Then I will implement autosuggestions function to make LLDB better in this project.</p>

<p>This project aims at enhancing the ability to detect and split small cold blocks (for example, __assert_rtn, throws) to the existing hot/cold splitting pass in LLVM. We will utilize both static analysis and experimental data from code profiling to identify patterns of small cold blocks that are splittable, and aim to implement these splitting capabilities without inducing superlinear compile-time overhead in the existing hot/cold splitting pass. We will also aim at fine-tuning the existing cost model of LLVM’s hot/cold splitting pass, such that the optimizer can “bail out” should superlinear compile-time overhead occur.</p>

This project aims to modernize the LLVM Integrated Tester (lit) to improve its execution speed and long-term maintainability. Performance is currently hindered by synchronous subprocess management and the high OS-level overhead of launching separate processes for routine commands. To address this, the execution engine will transition to a non-blocking, asynchronous model using asyncio, and core built-ins like cat and diff will be moved in-process to eliminate redundant interpreter startups. Additionally, the project will resolve functional limitations in internal shell utilities and leverage Scalene for data-driven performance profiling. Deliverables include a modernized Python 3 codebase, an asynchronous execution engine, integrated in-process built-ins, and a comprehensive performance evaluation report.

This proposal is based on the LLVM project for GSoC 2025 with the same title, from Tue Ly and Nicolas Celik. Discourse: https://discourse.llvm.org/t/libc-gsoc-2025-bfloat16-in-llvm-libc/84469. Bfloat16 (aka "Brain Floating Point") is a recently developed floating point format by Google. Similar to IEEE 754 binary16, it is applicable in machine learning and AI providing significant improvements in training and performance. It is officially standardized as std::bfloat_t in the latest C++23 standard. The goal of this project is to implement support for this type in LLVM libc. Deliverables: - Implement the type in a compiler and architecture agnostic way. - Implement generic basic math operations that work on all supported architectures. - Implement specialized hardware specific optimizations and compiler built-ins for higher performance. - Investigate higher math functions if time permits.

Clang-REPL is an incremental compiler that enables interactive programming in C and C++, combining the flexibility of a REPL with the performance of compiled languages. Currently, users must manually load dynamic libraries when Clang-REPL encounters unresolved external symbols. This project aims to improve the user experience by implementing an Auto-Loading mechanism that automatically loads the required libraries when missing symbols are detected. In addition to auto-loading, the project will introduce Runtime Re-Optimization using Profile-Guided Optimizations (PGO). By collecting profiling information at runtime, Clang-REPL will be able to re-optimize initializers dynamically, leading to better performance without user intervention. Deliverables: 1. An Auto-Loading system that seamlessly resolves missing external symbols. 2. Runtime Re-Optimization support based on profiling data to improve execution performance.

This project aims to integrate Swiftly with the Swift Extension for VSCode. It should allow users to install Swiftly and Swift toolchains in the VSCode editor toolchains directly within the VSCode editor. Currently, we have the “Swift Extension of VS Code,” which provides code completion and LSP integration, error annotations with applicable suggestions, automatic generation of launch configurations for debugging, automatic task creation, Swift PM integration, and test explorer view. Since different projects may require different versions of Swift toolchains, we want to integrate with Swiftly to provide a seamless toolchain selection experience in VSCode.

The objective of this proposal is to design and implement an in-context AI assistant, named Co-Pilot, tailored for assisting users in creating Concerto models. This AI assistant will be seamlessly integrated into the existing VSCode web-extension, Playground, or other chatbot marketplaces, providing users with intuitive access to AI-driven suggestions and guidance during model creation. Co-Pilot will support multiple foundational AI models, such as OpenAI, Bard, Anthropic, among others, and allow users to configure API keys for their preferred models. Additionally, the proposal aims to engineer LLM prompts effectively to aid users in editing Concerto models and measure the effectiveness of these prompts.

I propose reimplementing the compiler’s qualified name lookup in the Swift-only "swift-syntax" package. I will add a new API to the SwiftLexicalLookup module that accepts a declaration group, such as a type, and returns its members —commonly properties and functions. Lifting this API into the higher-level SwiftSyntax package exposes essential semantic information, enabling build tools that perform more intricate code transformations and offer more precise diagnostics. The library will find a declaration group's members through the package's SyntaxVisitor API and optionally cache results in a new SymbolTable type. I will deliver the updated SwiftLexicalLookup library with helpful docstrings and comments, extensive unit testing, and unqualified-lookup integration, along with two dedicated documentation articles.

The CIRCT project is an open-source effort to develop Circuit Intermediate Representations, Compilers, and Tools by applying the MLIR and LLVM development methodology and best practices to the domain of hardware design tools. In particular, it could act as a common platform and accelerate the development of interoperable design and verification tools, as opposed to today’s landscape of proprietary tools implementing their own disjoint and incompatible IRs. This project's idea is to demonstrate said verification prowess by implementing "circt-lec", a basic LEC (Logical Equivalence Checker) tool for combinational CIRCT designs. Specifically, it has to translate two circuits into their fundamental boolean equations and formally prove or disprove their equivalence through the aid of an existing SMT solver (an engine for determining whether mathematical formulas are satisfiable).

<p>OpenRISC’s mor1kx is one of the old open source projects with more sophisticated and multi-core features. FuseSoC support for mor1kx makes it unique, enabling users to run their assembly programs in a virtual SoC. The or1k-elf toolchain compiles assembly programs, simulated using Icarus Verilog to visualize waveforms. Mor1kx processor went through several tests to verify its functionality, and the or1k-tests successfully identified many unseen bugs in the design.</p> <p>But we can’t guarantee that the processor is error-free. Formal Verification identifies the hidden bugs in the design. This verification methodology gives confidence that the system remains stable for a long time. Hence in this project, the mor1kx processor is thoroughly tested using Formal Methods, ensuring that implementation meets its specifications.</p>

The goal of this project is to enable support for the High-Level Shading Language (HLSL) in clangd, allowing shader developers to benefit from modern language-server features such as code completion, diagnostics, semantic highlighting, and symbol navigation. Although HLSL is largely based on the C++11 standard and can already be parsed by Clang, clangd’s support remains incomplete due to missing handling of HLSL-specific constructs, semantics, and resource types. Additionally, shader development introduces unique challenges, such as multiple entry points within a single file (e.g., vertex and pixel shaders), which are not fully addressed by clangd’s current architecture. The project will begin with an evaluation of clangd’s behavior on HLSL code to identify gaps, followed by the design of appropriate extensions. An RFC will be proposed to the LLVM community to validate the design and gather feedback. Based on this, the project will implement key improvements to clangd, focusing on built-in function completion, semantic analysis of shader constructs, improved diagnostics, and better handling of shader-specific configurations. The final deliverables include a documented analysis of current limitations, an RFC describing the proposed design, a structured set of implementation issues, and upstreamed improvements to clangd, along with test coverage and documentation.

Currently, the debuginfo test suite has a number of shortcomings: it is sensi­tive to the installed debugger and python version; it does not account for the unavoidable visualization difference between PDB and DWARF debug info; the raw string comparisons are fragile and cause unreasonable numbers of failures when visualizer scripts are changed intentionally; and many properties the visualizers rely on are only tested incidentally. As a result, the tests are difficult to run in CI, difficult to run locally (particularly on Windows), failures are difficult to diagnose, and updating tests for expected changes is arduous. This proposal intends to add a new directive ("{debugger_prefix}-repr") to compiletest/runtest/debugger that leverages the debuggers’ public Python API. Python scripts will check the debugger’s in-­memory representation of objects and the underlying debugee memory to verify accurate debug info and visualization. These scripts will also be able to alter their behavior based on debugger version and debug info format. This will allow for more specific errors when tests fail. Test data will be “bless­able” (i.e. automatically updateable) to make intentional changes to the visualizer scripts significantly easier.

The APAP MCP server currently routes every tool call through an internal HTTP loop back to its own Express server, adding unnecessary latency, making MCP handlers impossible to unit test, and discarding all HTTP error context behind generic error strings. The MCP layer has zero automated tests and no client-specific documentation beyond a basic setup guide. This project introduces a shared service layer that both MCP tools and REST routes call directly via Drizzle ORM, eliminating the HTTP round-trip. Structured error types replace generic strings with machine-readable codes and HTTP status preservation. Deliverables: 1. Shared service layer refactor with structured error types across all 8 MCP tool handlers 2. Four-tier test suite (unit, integration, contract, E2E) with 90%+ coverage enforced in GitHub Actions CI 3. Client-specific tutorials for Claude, ChatGPT, and MCP Inspector 4. Developer experience improvements: Docker Compose quickstart, Pino structured logging, /healthz endpoint, and updated CONTRIBUTING.md A working proof-of-concept implementing the core refactor with 53 tests and 98.55% statement coverage is already live at github.com/JayDS22/apap-mcp-poc.

Swift’s type inference algorithm allows us to write source code without explicit type notations. It is implemented using a type checker that breaks up the source code into subexpressions and generates their abstract type variables and type relationships to create a constraint system that maps out all of these components of the subexpressions of the source code and helps the compiler deduce the missing concrete type information from this context. These type variables, their interrelationships, and the final type-checked expressions can be printed as debug information to help compiler developers understand this process. However, the current debug output is hard to understand, wordy and repetitive, with a format that is difficult to follow. This proposal will reorganize and rewrite the debug output of the type inference algorithm to make it more human-friendly and improve the debugging experience for new and experienced Swift compiler developers.

Graphite currently offers only a limited set of shape tools with basic gizmo support, limiting the scope of creative and precise editing. This project aims to enhance the Polygon Tool by introducing a variety of predefined shape nodes—such as Trapezoid, Star, Donut, Pie, Crescent, and more—each equipped with custom, interactive gizmos. To manage these features, a centralized Gizmo Manager will be developed to handle both general transform cages and shape-specific gizmo points. These gizmos will integrate with the Select Tool using a state-driven interaction model to enable intuitive, fine-grained shape manipulation. Each shape will expose unique transformation controls (e.g., adjusting edge curvature, radii, angles, and segment lengths), allowing users to craft complex designs efficiently.

<p>This project aims to extend Graphback by adding additional capabilities by building custom plugins. Plugins will provide Data Synchronization and Conflict resolution by optional integration with Debezium. Additionally, this project also aims to prototype an example application using the Graphback runtime with Debezium integration and deploy it using Knative.</p>

<p>The aim of this project is to carry out a rigorous and deep case study of Index Checker by annotating Apache Commons Lang with the same. The plan of action is to annotate, find and report bugs(if any) and provide enhancement suggestions, including improvement in the error messages. If there is time left, I'd repeat the above procedure with the same tool on a different package.</p>