Explore Projects

Improve compiler diagnostic suggestions and span formatting for async/await closure type mismatches.

<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>

<p>The Index Checker warns about potentially out-of-bounds accesses to sequence data structures in the widely used Google Guava library, guarantee annotated packages are free from ArrayIndexOutOfBoundsException error. This case study will also expose the checker's current limitations to improve its capabilities and precision. Another goal of this project is to enhance Index Checker error messages, to make it more intuitive for programmers.</p>

GHC is Haskell's most advanced compiler, supporting Haskell2010 report as well as several compiler extensions. Yet, GHC is not fault-tolerant, an error in an early stage in the compilation pipeline, i.e. parse error, halts the pipeline. This prevents several potential errors from being reported. The compiler reports only errors in the current pipeline stage. To solve this, the compilation pipeline should run completely even when there are errors in an early stage, this requires modifying the pipeline stages to generate/accept partial output, an abstract syntax tree with fault nodes annotated.

In order to make LFortran reach beta quality, it is essential to compile more benchmarked fortran codes. FPM(Fortran Package Manager) is one of the best example of such codebase. Successfully compiling FPM will make LFortran a more robust compiler and it will be a huge boost for LFortran to reach at beta quality. For this year's GSOC project, I am planing to compile FPM with LFortran. Since FPM depends on other 5 open source fortran codebases (toml-f, fortran-regex, fortran-shlex, M_CLI2, jonquil) , my plan is to compile those 5 small codebases till 1st month of coding period. To compile any code, my idea is to create workarounds that compile with LFortran till code compiles fully with LFortran, then create MREs for each workarounds and finally fix them and remove workarounds from original code. This way I will compile in order: toml-f, fortran-regex, fortran-shlex, M_CLI2, jonquil so that all dependencies are solved well. After completing these 5 codes, I will follow same process to compile FPM. Detailed weekly plan is discussed in my proposal. Deliverables: Compile toml-f, fortran-regex, fortran-shlex, M_CLI2, jonquil, FPM completely with LFortran.

I propose enhancing LFortran so that it can compile the majority or all of SciPy's Fortran code to binaries, allowing SciPy to be entirely compiled using LFortran and Clang. Currently, LFortran can compile the majority of Fortran files to ASR (Abstract Semantic Representation); however, there are some lacking features, such as COMMON, BLOCK DATA, SAVE, etc., that must be implemented for it to function properly. I have supplied multiple implementations that will allow these features to function effectively in the vast majority of circumstances. When lacking features are successfully implemented, the majority of the codebase will compile to LLVM. First, I will concentrate on the following packages: specfun, odepack, quadpack, fitpack, and Arpack, and then I will shift to other packages. By compiling SciPy, LFortran would acquire a larger user base, which would in turn encourage additional testing and development.

Incremental compilation is a technique that helps increase compilation speed by recompiling only changed files instead of your whole program (also known as performing a clean build). By the time of this project, the Kotlin/Wasm compiler supports only clean builds. This project enhances the Kotlin/Wasm compiler to support incremental compilation, thereby improving the development experience by reducing build times and increasing productivity.

In the upcoming GSoC project, I will be compiling Stdlib codebase using LFortran. This codebase can be compiled by any modern Fortran compiler, such as GFortran. For various packages of Stdlib, my plan is to discover bugs and failures in various phases of LFortran (Frontend, ASR passes, and Backend) and report minimal reproducible examples for these bugs. My next step will be to fix all the reported bugs to ensure the successful generation of executables. Finally, I will be working to align the outputs from LFortran, for various Stdlib packages, with those of GFortran. Additionally, I will also work to implement some new features like Submodules which are required for the compilation of Stdlib but are not currently supported by LFortran.

<p>This project should broaden the functionality of being able to specify flags for compilation profiles, which is so far quite limited. It should also allow the support of different argument types. Therefore the user should be able to specify project local arguments, which are not overwritten by main package arguments when a project is used as a dependency and also argument types, which are applicable for the whole project.</p>

LFortran is a modern, interactive Fortran compiler built on LLVM that aims to support real-world Fortran codebases. This project focuses on enabling full compilation and correct execution of two real-world Fortran packages benchmark.f (a benchmarking library) and feq-parse (an equation parser) using LFortran. Significant pre-GSoC progress has already been made: benchmark.f currently compiles to 76% and feq-parse to 40%. The remaining blockers include missing quadruple precision (REAL(KIND=16)) support, deserialization ICEs for forward-referenced symbol tables, ExternalSymbol resolution failures for struct-scoped types, ASR verifier false positives for GenericProcedure constructor calls, and an LLVM IR type mismatch in character length handling. The project will follow an iterative, compilation-driven workflow: attempt compilation, identify failures, reduce to MREs, fix the compiler, and validate against gfortran. Every fix will be accompanied by integration tests to prevent regressions. Deliverables: - Full compilation of both benchmark.f and feq-parse with LFortran - All example programs and test suites passing with gfortran-consistent output - End-to-end quadruple precision support across parsing, ASR, and LLVM backend - All fixes merged as pull requests with integration tests

This proposal aims to improve LFortran by compiling and validating real-world Fortran packages such as M_intrinsics, fman, and gtk-fortran. Instead of focusing on isolated features, it follows a compilation-driven approach to identify and resolve limitations across different stages of the compiler, including parsing, semantic analysis, code generation, and runtime support. Key issues such as incomplete I/O specifier handling, quadruple precision support, and array constructor transformations will be addressed. The project emphasizes iterative development, testing, and validation against reference compilers, with the goal of improving LFortran’s robustness, correctness, and support for complex, real-world applications.

<p>The Haskell IDE Engine is a Haskell backend for IDEs, which utilises the Language Server Protocol to communicate between clients and servers.</p> <p>This projects aims to create a test framework that can describe a scenario between an LSP client and server from start to finish, so that functional tests may be written for the IDE engine. If time permits, this may be expanded to be language agnostic or provide a set of compliance tests against the LSP specification.</p>

<p>Parsing Expression Grammars (PEGs) are an expressive formalism for designing and implementing top-down parsers with local backtracking. An issue that users of PEG-based parsers face is poor reporting of syntax errors on the part of PEG-based parsers. Labeled failures are an extension to PEGs that aims to address this issue by annotating a PEG with labels corresponding to syntax errors, improving the quality of error messages generated by a PEG-based parser.</p> <p>LPegLabel is an extension of the LPeg tool that provides an implementation of PEGs with labeled failures. Labels can be used to signal different kinds of errors and to specify which alternative in a labeled ordered choice should handle a given label.</p> <p>The goal of this project is to rewrite the parsers of some Lua libraries, such as the module re from LPeg and lua-parser, by using LPegLabel. After this rewriting we should get parsers with better error messages.</p>

Rocket.Chat’s Message Composer currently displays raw Markdown syntax and emoji shortcodes while composing a message, only applying formatting after the message is sent. This impacts readability and usability, as users must interpret raw syntax instead of seeing the final formatted output. This project will introduce real-time Markdown rendering and native emoji support in the Message Composer. Users will be able to see bold, italic, and other formatted text as they type, along with correctly rendered emojis. Additionally, the project will provide a proof-of-concept for migrating from Rocket.Chat’s third-party emoji pack to native emoji support. Key Deliverables: 1. MVP implementation of real-time Markdown rendering in the Message Composer. 2. Native emoji support, replacing the existing third-party emoji pack. 3. Support for mentions with a defined style, ensuring visually distinct tags. 4. Text sanitization to maintain security and prevent unintended behavior. 5. Help tooltip for Markdown syntax, improving accessibility for new users.

Improving the clang diagnostics focuses on the diagnostic section of clang. This proposal is meant to make clang diagnostic more user friendly and efficient. we will be comparing with gcc and also trying to taking surveys to improve the diagnostic tab of clang. Thus will mainly focus on the betterment of Diagnostic tab of clang.

This project aims to reduce the amount of time that LLVM spend on compiling code by focusing on hotspots in the code identified by profiling workloads both with and without optimization passes enabled. The main possibilities for improvements are identified in SelectionDAGISel (specifically DAGCombine), InstCombinePass and InlinerPass. Aside from these, the analysis passes and some machine passes are also identified as good opportunities for optimization. At the end of this project, there will be a noticeable improvement in compile times for the test cases considered and an overall improvement (if small) in general compile times for all inputs. Fatal cases from the LLVM GitHub issues page where compile time explosions occur will also be considered to fix edge cases where super-linearity of the optimizations come into play or where an extreme amount of input causes outliers in the compile time share of certain passes.

Clang diagnostic is an interface for programmers that assists them in writing bug-free, efficient source codes. The aim of this proposal is to improve overall clang diagnostics and its usability by resolving existing issues labeled clang:diagnostics and possibly uncovering and resolving new issues we encounter throughout the project.

SE-0249 introduced key path expressions as functions to the Swift language, to allow Swift users to write a more concise \Root.value in place of the more verbose { $0[keyPath: \.<member>] } wherever key paths are used as literal expressions. During compilation, the key path expression root and value are sequentially type-checked to resolve a key path type from this context. However, the current design of how the type-checker evaluates key path component types, their relationships to each other, and key path capabilities results in incongruous compiler errors for otherwise valid Swift code. This proposal briefly explores how key path expressions are type-checked today and suggests how this type-checker process can be made more robust, dependable, and faster.

LLVM generates valuable information through remarks, profiling, and runtime annotations that becomes difficult to navigate as projects grow. This project aims to create a unified infrastructure to collect, organize, and visualize compilation data from the LLVM offloading toolchain. The tool will function as a compiler wrapper that captures JSON-formatted information and presents it through an interactive web interface. By providing accessible visualization of optimization decisions, profiling data, and compilation metrics, the tool will help developers make data-driven decisions rather than relying on trial and error.

This project aims to provide an analysis of the causes of unexpected compilation times. By conducting a statistical analysis on IR files available on the LLVM ComPile dataset, outlying files that yield unexpected compilation times can be detected. Python scripts will assist in the extraction and subsequent analysis of the IR files at multiple optimization levels. Identification of those outlying files will lead to an analysis of features in or related to the IR using available tools for analyzing LLVM code. Available flags for the compiler of a given language, say Clang, can be used to identify statistics, such as pass times, related to the compilation pipeline. Pinpointing what features are specific to code compilation, such as certain passes, and how IR features relate to the compilation pipeline will inform compiler implementers and LLVM developers as to what specifically causes an unexpected compilation time. Implementers can then modify the compilers accordingly, and developers can write code in conformance with specific programming structures, in order to minimize compilation times.

GSoC Project "Instrumentation of Clang/LLVM for Compile Time" aims to solve a simple but interesting question: Why is the compilation taking so long? We will improve the existing timing infrastructure to make the timing tools more efficient. Specifically, we improve the timing trace model to effectively time nearly all compilation stages. After that we can make statistical analysis based on the trace data, such as hotspots identification and so on. Finally, we implement the timing information collecting mechanism based on the library use case. This helps LLVM based languages or tools use related functions to easily troubleshoot its performance bottlenecks.

<p>Compilers come with hundreds of optimization passes, making it difficult to select which passes to run and deciding the order in which to execute them. Typically, compilers achieve this by running the standard optimization pass pipelines. However, customized sequences of passes for a particular program can significantly improve the performance compared to the standard optimizations.</p> <p>So it is important to study the dependencies between these optimizations passes, and how they affect the code structure. This will pave the way to improve the existing heuristics for ordering the compiler optimization passes; heuristics that can select the optimal pass order depending on the code structure.</p> <p>Another interesting approach is to use machine learning to optimize the compiler rather than rely on heuristics. Making machines learn how to optimize the compiler, is a faster approach to produce target-specific optimizations for the underlying platform, as well as for the code structure. For instance, machine learning can be used to identify patterns in code structure and then select the ideal optimization sequences specific to those patterns to get high performance for that program.</p>

<p>One of the selling points of new LLVM ORC Concurrent JIT APIs is we can speculatively compile functions before we need it, with the hope that when we call it in run-time it is already compiled. However, if we speculatively compile the whole module and its transitive dependencies we’re quickly going to overload the CPU/Memory resources and increase the start-up time of the application. To avoid this, we can select the functions ahead of time which are likely going to execute next and compile them speculatively, using runtime profiles from previous app executions and/or static program analysis.</p> <p>It helps to use leverage the performance of Just-in-time compilation using modern multi-core machine. It also helps to reduce the JIT compilation latency.</p>