Swift

Mentors: Student: Ege Kaya

Swift's concurrency runtime has no mechanism to enumerate live Tasks and TaskGroups. When a program using async/await stalls, existing tools such as thread backtraces, Instruments, LLDB are silent about the suspended tasks that are the likely cause. Instruments records task lifetimes after completion; there is no API, debugger command, or crash report field that answers "what tasks exist right now and what are they waiting on?" This project implements a global registry of live AsyncTask and TaskGroup instances inside the Swift Concurrency runtime. The core challenge is doing this without introducing unacceptable synchronisation overhead on every task creation and destruction, a hot path in any concurrent Swift program. I will implement and benchmark at minimum two candidate data structures: a sharded-mutex intrusive list (using PrivateStorage, which is opaque externally and safe to extend without breaking ABI) and a lock-free Treiber stack alternative. Deliverables: A working registry implementation with hooks in swift_task_create_commonImpl and AsyncTask::~AsyncTask() A design document comparing candidate data structures with measured overhead against the existing TaskGroups.swift and AsyncTree.swift benchmark suite Signal-safe crash backtrace integration listing live tasks on crash LLDB Python macros for interactive task inspection.

Mentors: Student: Padmashree S S

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.

Mentors: Student: Filip Sakellariou

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.

Mentors: Student: Ahmed Elrefaey

Currently, SourceKit-LSP only shows the first line of the documentation for code completion items. Furthermore, it doesn’t support the Language Server Protocol’s (LSP) signature help request which provides information about the function or subscript being completed like alternative signatures, documentation, parameter list, and parameter-specific documentation. The goal of this project is to enhance how SourceKit-LSP displays documentation for code completion items by: 1. Providing the full documentation for code completion items rather than the first line only. 2. Implementing LSP’s signature help request to provide richer guidance for completing function/subscript signatures. The implementation will require changes in SourceKit-LSP and sourcekitd in the Swift compiler codebase. This will enhance the developer experience for Swift developers using SourceKit-LSP on editors like Visual Studio Code and Neovim aligning with Swift’s vision of cross-platform support.

Mentors: Student: Mads Odgaard

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.