Explore Projects

This project aims to extend SourceKit LSP to add DocC Language features like go-to-definition and diagnostic support for missing or broken symbol links. It also enhances the documentation preview by making it interactive with clickable symbol links and web URLs, along with syntax highlighting for .tutorial and .md files.

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.

Providing excellent tooling for Swift often involves operating on Swift syntax trees directly. The swift-syntax library serves this purpose by providing a Swift representation of syntax trees, along with facilities to parse and generate Swift code. To make code generation especially convenient, the library includes a Domain-Specific Language (DSL) for building syntax trees that, however, currently relies on external tooling to generate a large part of its own definitions. To test the DSL on a non-trivial codebase and to make it production-ready, we will rewrite the syntax builder in itself, generating its sources using its own DSL and thereby bootstrapping its implementation.

<p>Diagnostics play a vital role in a programming language experience. It’s vital for developer productivity that the compiler can produce proper guidance in any situation, especially incomplete or invalid code through messages. However, the diagnostic messages might be helpful in much time; for the non-English speakers, it’s not.</p> <p>As a step towards the goal of making Swift programming language more accessible for non-English speakers, this proposal extends the Swift compiler to allow it to produce localized diagnostic messages.</p>

This project enhances the console output experience for the Swift Testing framework by designing and implementing a new, two-phase console reporter. This architecture provides both real-time feedback during test execution (the "Live Phase") and concludes with a comprehensive, structured report (the "Summary Phase"). The primary focus during this GSoC project was the implementation of the Summary Phase, which includes: - A rich Hierarchical Summary that visualizes the relationship between test suites and individual tests. - A dedicated Detailed Failure Report providing clear, actionable information for debugging. - Intelligent cross-platform support, with an ASCII fallback for terminals with limited Unicode compatibility. Architecturally, the reporter was refactored to consume a serialization-based event stream (ABI.EncodedEvent). This was a significant technical pivot that decouples the reporter from the test runner, preparing it for future integration into an out-of-process "harness". The final deliverable is a robust, experimental implementation available behind a feature flag, with a clear roadmap for completing the Live Phase post-GSoC.

<p>Swift supports multiple levels of optimizations per single module. This project aims to achieve LTO support for Swift at LLVM level and at Swift’s intermediate representation level to do more aggressive optimization across modules.</p> <p>This proposal suggests language-agnostic LTO support and linker plugin implementation for Swift specific LTO.</p> <p>The linker plugin will be able to accept serialized Swift Intermediate Language (SIB) files for multiple modules and performs cross-module optimization passes (e.g. Dead Code Elimination, Inlining).</p> <p>As a result, it’s expected to achieve significant binary size reduction and runtime performance improvements.</p>

Considering the performance, instead of reparsing the entire file every time, we could speed up the parsing procedure with the information provided by old AST, which is an ability provided by the old parser. In the old implementation, this feature was only applied to CodeBlockList and MemberDeclList. In the new implementation, It would be nice to apply node reusing to other syntax collections e.g. exprList, functionParameterList, etc. Also, It would be good to allow more fine-grained reusable nodes via expanding the definition of nodeAtCursorCanBeReused to allow reusing nodes such as FunctionDeclSyntax where only identifier is changed.

<p>The <a href="https://docs.google.com/document/d/1dOK9FYKf2egZcYqrR3rdtF8o2ykTdVxwuuwZcrs5lwQ/edit#heading=h.b4gt1ulsb82o" target="_blank">Alive for SIL</a> project aims to build a tool that will find errors in optimizations performed by the Swift compiler.</p> <p><a href="https://swift.org/swift-compiler/#compiler-architecture" target="_blank">SIL</a> (a.k.a. Swift Intermediate Language) is an IR (a.k.a. intermediate representation) used within the Swift compiler between the Swift AST and LLVM IR. SIL enables the Swift compiler to perform Swift-specific optimizations.</p> <p><a href="https://sf.snu.ac.kr/publications/alive2.pdf" target="_blank">Alive</a> is a tool that formally verifies the correctness of optimizations performed on LLVM IR and produces counterexamples when such optimizations are incorrect. For example, if an optimization accidentally adds undefined behavior into a program, then Alive2 would be able to find this error and produce an example that exposes the undefined behavior.</p> <p>This project aims to extend Alive to verify the correctness of optimizations performed on SIL.</p>

This proposal aims to improve the testing framework for SW360’s REST API endpoints by addressing limited test coverage, insufficient integration tests, and outdated testing workflows. The project will focus on writing comprehensive unit tests for CRUD operations and edge cases, developing integration tests for multi-endpoint workflows, and creating reusable utilities for database mocking and error simulation. Additionally, CI/CD pipelines will be automated with tools like JaCoCo for test coverage tracking and regression prevention. Deliverables include a robust test suite, enhanced testing infrastructure, automated pipelines, and detailed documentation to simplify onboarding and contributions. These improvements will make SW360's APIs more reliable, scalable, and maintainable for the developer community.

The swift-java interoperability library provides the jextract-swift tool, which extracts Java sources that are used to call Swift code from Java. However, the tool uses the Foreign Function and Memory API (FFM), which requires JDK 22+, making it unavailable on platforms such as Android. The goal of this proposal is to extend the jextract-swift tool, such that it is able to generate Java sources using JNI instead of FFM and thereby allowing more platforms to utilize Swift/Java interoperability. The solution will modify the code generation to support multiple modes through a protocol. Thereby, allowing us to generate JNI Java wrappers that that utilize the JNI functionality already defined in the library. We will modify the current Arena implementations to support memory management for JNI as well, through calls to the Swift runtime. The library will also generate Swift thunks that implement the native methods defined in Java and handle JNI/Swift conversion and object initialization. The project will achieve feature parity with the current FFM mode and explore more complex language features, if time permits.

“Implementing a Code Action in Visual Studio Code to show the expansion of a Swift Macro in a peeked editor”. Swift Macros allow the generation of source code at compile time. While this provides concise code and avoids repetition of common paradigms, understanding the source code can become harder if it is unknown what the macro expands to. Visual Studio Code using the Swift Extension currently has limited ability to show the code generated by a macro by invoking a code action that replaces the macro by its generated code inside the current source file. The project’s goal is to implement a code action to show the macro-generated code without modifying the current source file. This includes the implementation of a request in sourcekit-lsp to compute the contents of the macro expansion and support in the Visual Studio Swift Extension to display that content. As a stretch goal, Visual Studio Code should also offer semantic functionality like jump-to-definition inside the macro expansion and allow the expansion of nested macros. *Deliverables*: 1. An Expand Macro Code Action in VS Code that shows the generated contents of a swift macro in a peeked editor 2. Support for Semantic Functionality such as jump-to-defintion, hover, syntax highlighting in the peeked editor 3. Allow expanding macros generated from macro in the peeked editor i.e. Nested Macro Expansion 4. Add a standard request support for other LSP-based editors giving them ability to expand macros upto the first level.

This project is proposed because of the need for a fully-integrated HTTP server in Zephyr that can replace the deprecated CivetWeb module. The proposed solution is to prototype a basic HTTP 2.0 server using POSIX APIs and then port it to Zephyr. The server will take advantage of Zephyr's existing building blocks, including the ZTest Framework, mbedTLS libraries, Kconfig ... The project's deliverables include a basic HTTP server, porting the server to Zephyr, and creating a Test Plan to demonstrate mandatory features such as REST API, TLS, and Compressed Resources in Memory (CRiMe). Additionally, we will demonstrate HTTP server functionality with one of Zephyr's supported boards and Qemu.

<p>Components are the building blocks of app inventor. They can be visible i.e. they are part of UI interface or they can be non visible i.e they are not part of the UI screen but provide access to built-in functions of the device. All components in app inventor are part of some screen or activity which means that if the screen is not visible or the screen is destroyed by the Android system, the components stop running. An example of this is the Pedometer component which stops running when the phone screen is off. Ideally, a pedometer app would want to keep running once started in the background until the user of the app explicitly stops it. To enable such behavior it is necessary to run such components in a background process and re-start the process every time the system kills it.</p>

<p>Currently, extensions are limited to just non-visible components. Due to this, extensions can't be dragged into the screen designer. To work around this, extension developers have to get a reference to a visible component as parent under which they create UI views. This, however, defeats the idea of App Inventor, which allows the users to create their UI of their apps using the concept of WYSIWYG. My proposal to solve this problem is to have a generic <code>MockVisibleComponentExtension</code> which can be dragged into the designer. The extension will be just a visible component as opposed to non-visible component. This allows the extension to be placed under a <code>ComponentContainer</code> under which the extension can create its views. This allows the users to view a clear hierarchy of their app's UI when using "visible" extension. Then, there will also be a need for <code>MockComponentContainerExtension</code> into which any visible component/extension can be placed.</p>

<p>Processing Language Server focuses on creating a Language Server Protocol (LSP) implementation for Processing Programming Language. PDE is currently built using Java and using custom components of the Swing Framework, which is ~ deprecated. The long term goal of Processing is to replace this with a JS based IDE to bring in more contributors and to make building UIs simple. While planning on building such IDE, LSP is of significant importance for any language that the IDE relays on. Since Processing is the targeted Programming language, it’s quite important to build a Language Server Protocol for the same. This shall act as a benchmark for all the crucial activities of the IDE such as auto-completion, go-to-definition, hover-insights and so on. LSP will also help in easy and seamless integration of the above functionalities in any editor such as Atom, VScode, etc.</p>

<p>Integrated script editor in Godot lacks features found in editors like VS Code, Sublime, Emacs, etc. These editors are also more popular among developers and therefore are better to switch for usability. However, to implement core functionalities such as - Diagnosis, Registering custom symbols, jump to definition, etc a Language Server structure has to be adopted. For example, the client (say vs code) will communicate the godot language server to give desired result.</p> <p>Microsoft's Language Server Protocol (LSP) is flexible and powerful to implement these functionalities. It also supports many editors - VS Code, Atom, Sublime, etc. Hence, instead of writing complete extensions for each editor (client) using LSP servers can be reused while the client which is an editor extension has to be only re-written.</p>

<p>Right now, MIT App Inventor is short of components that allow to visualize data using charts. This project aims to implement entirely new components that allow displaying the data visually, such as through pie charts, bar charts, scatter charts or radar charts, while also providing various customization functionality to allow the user to adapt the components to their needs.</p>

This proposal aims to improve the dashboard's performance and overall code-quality by making a variety of changes to the frontend codebase. this involves converting all React class components to functional components, replacing the remaining jquery code with vanilla JS code and updating to a newer version of React (React 18). This proposal will essentially modernize a large portion of the frontend codebase. Allowing for an easier developer and user experience.

Scope: To create a standalone React component from MatchMiner that will use Firebase to provide trial curation across multiple projects uses Requirements: • Familiarize with React, MatchMiner, OncoKB Angular and Firebase Execution • Study previous MatchMiner implementations to leverage that information into the current implementation plan • Refactor Match Miner component • Code formatting • Create standalone component that can be reused across multiple projects • Employ best practice on naming conventions and proper de-structuring Constraints: • Time • Lack of working experience in Angular Risks: • Can only build upon the component, cannot transform or remove features • Unexpected consequences of changes and ensuring failures will be localized to the component Deliverables Task 1: Strip down Match MinerAngular to base component, its most reusable part, via a DRY method. Task 2: Re-factor MatchMiner in React that will be extendable as a stateless component Task 3: Ensure library component in React is developer friendly in order to not burden the End Dev Task 4: Testing in staging environment to ensure proper functionality

The current OpenELIS React frontend is primarily written in JavaScript and faces challenges in maintainability, scalability, and performance as data complexity increases. This results in inconsistent type usage, increased bugs, and inefficient rendering in data-heavy workflows such as patient management, sample tracking, and result entry. This project aims to modernize the frontend by incrementally migrating the codebase to TypeScript and applying proven React performance optimization techniques. The migration will introduce a centralized type system for API models, forms, and reusable components, ensuring consistency and reducing duplication across the codebase. The project will follow a phased approach: first establishing a strong TypeScript foundation with shared type definitions, then incrementally migrating utilities, components, and high-impact screens. In parallel, performance optimizations will be implemented using profiling-driven techniques such as memoization, virtualization for large datasets, improved server-state handling, and code splitting. Deliverables include: - Incremental migration of frontend codebase to TypeScript - Centralized and reusable type definition system - Performance improvements in key workflows - Reduced bundle size and improved rendering efficiency - Documentation and migration guide for future contributors This project will significantly improve the maintainability, developer experience, and performance of the OpenELIS frontend, making it more scalable for future growth.

<p>An MPD Server would be very helpful for remotely controlling the VLC Media Player. There are many great MPD Clients (including open source ones) available for many platforms, therefore one can choose a client that suits them best in order to control VLC, once a version of VLC with an MPD server is available.</p>

This proposal aims to enhance MIT App Inventor by developing artificial intelligence (AI) components for iOS platforms. By re-implementing existing AI features, the project seeks to democratize AI development and empower users to seamlessly integrate AI functionalities into their mobile applications. The deliverables include designing and implementing these components, integrating them into the MIT App Inventor platform, providing comprehensive documentation and tutorials, and conducting thorough testing for reliability and performance. Ultimately, this endeavor strives to foster innovation and creativity in mobile app development while making AI accessible to a broader audience.

<p>Writing XMPP components is a good way to enhance the functionality of XMPP servers like ejabberd. Jabber Component Protocol (XEP-0114) is used today for this goal. However, this protocol is quite limited. The goal of this project is to implement XEP-0356 Privileged entity and XEP-0355 Namespace delegation server extensions to XMPP that will allow to run more powerful component on ejabberd. Implementation of these extensions can help to extend ejabberd functionality with existing powerful components like Collecta or SàT and give an impulse to create new services.</p>