This repository is a curated, structured dataset of C and C++ standard features (from C99 to C++29) with per-compiler support status across multiple toolchains (GCC, Clang, MSVC, Xcode, etc.). It includes YAML data files defining features, toolchain releases, and frontend metadata, along with a C++ validation tool that enforces schema compliance and semantic consistency (e.g., verifying that referenced tool versions exist and issue trackers are properly used). The dataset is designed to power a reference website (cppstat) and is accompanied by detailed Markdown explanations for each feature. While the primary artifact is the data itself, the validator and CI pipeline demonstrate strong data engineering practices, making the repository a reliable source for compiler feature support information.
Gravity is an embeddable, dynamically typed scripting language written in portable C99 with no external dependencies beyond the C standard library. The repository implements a full language toolchain: a multi-pass compiler (lexer, Pratt parser, AST, IR, optimizer, bytecode codegen) and a register-based virtual machine with mark-and-sweep garbage collection. It provides a CLI (`gravity` executable) for running scripts and a well-defined C embedding API. The architecture is modular, with clear separation between compiler (`src/compiler`), runtime (`src/runtime`), shared utilities (`src/shared`), and optional modules (Math, File, JSON, ENV). The codebase is extensively tested with unit tests (embedded `#unittest` blocks) and a large fuzzing corpus for crash resistance. Despite some monolithic files (`gravity_core.c` >4000 lines) and heavy macro usage, the implementation demonstrates strong software engineering craftsmanship, especially in the hash table, dynamic array macros, and Pratt parser. The project appears to be under active maintenance (last commit 2026-08-05, 34 open issues, 4.5k stars) but shows some technical drift such as outdated CI configurations, platform-specific ifdefs, and a fuzz corpus from 2017.
WebPd is a compiler and runtime system that translates Pure Data (Pd) audio patches into JavaScript or WebAssembly, enabling real-time audio synthesis and processing in web browsers and Node.js environments. The codebase is structured as a TypeScript monorepo with a CLI tool (`webpd`), a browser runtime using AudioWorklet, and a comprehensive library of Pd object implementations (147+ objects). The core compilation pipeline parses `.pd` files, resolves abstractions, optimizes DSP graphs, and generates self-contained output formats including `.js`, `.wasm`, `.wav`, and standalone HTML apps. The architecture is modular: the `src/nodes/` directory contains individual builder and runtime implementations for each Pd object (osc~, dac~, filters, delay lines, message objects, etc.), all following a consistent `NodeBuilder` pattern with `translateArgs` and `build` methods. The compiler (`src/compile-dsp-graph/`) handles graph transformations like implicit signal mixing and message-to-signal conversion. The runtime layer (`src/environments/browser/`) provides initialization, AudioWorklet integration, and message passing between JavaScript and the compiled patch. The codebase demonstrates strong engineering practices with extensive parameterized tests that verify both JavaScript and WebAssembly outputs against golden fixtures. However, it is in alpha status (v1.0.0-alpha.14) with many incomplete features (e.g., `readsf~` state machine, `list` operations, `expr` if-form) and several TODO comments. The project relies on internal packages (`@webpd/compiler`, `@webpd/pd-parser`) that require coordinated builds, and some generated code strings are embedded in runtime files, creating potential maintenance friction. Despite these caveats, the compiler design, test infrastructure, and Pd compatibility are noteworthy.
Amber is a Rust-based compiler that transpiles a high-level, statically-typed programming language into shell scripts (Bash, Zsh, Ksh). It provides a modern language with features like functions, type inference, generics, optional arguments, failable types, imports, loops, range expressions, array operations, and a standard library for file system, text, HTTP, math, and environment operations. The compiler architecture is modular: a CLI entry point (src/main.rs) dispatches to subcommands (build, run, eval, check, docs, test). The compilation pipeline (src/compiler.rs) orchestrates tokenization via heraclitus-compiler, parsing into a typed AST, type checking with control-flow analysis, translation to an intermediate fragment AST, optimization passes (unused variable removal, ephemeral variable elimination), and final shell code generation with post-processing (e.g., shell syntax checking). The system supports multiple shell targets and generates version-specific code. The codebase is well-structured with procedural macros (meta crate) for keyword registration and context management, and a comprehensive test suite using snapshot testing (insta). While alpha quality, the engineering is serious and the architecture shows thoughtful design patterns.
This repository implements `cuda_tile`, an MLIR-based compiler dialect and toolchain for GPU tile programming, primarily targeting NVIDIA CUDA architectures. It defines a rich set of operations for tile-level computation (arithmetic, matrix multiply, memory views, atomics, control flow) with explicit memory ordering and synchronization. The project includes a custom bytecode serialization format (.tileirbc) with versioned backward compatibility, allowing efficient IR transport and JIT compilation. Key tools are `cuda-tile-opt` (dialect testing), `cuda-tile-translate` (MLIR-to-bytecode conversion), `cuda-tile-optimize` (bytecode-to-bytecode optimization passes), and `cuda-tile-tblgen` (TableGen-based code generation for bytecode readers/writers). Python bindings enable programmatic IR construction. The architecture is a set of modular libraries (dialect, bytecode, optimizer, C API) that can be integrated into larger compiler pipelines. External dependencies are LLVM/MLIR at a pinned commit and CUDA. The codebase demonstrates high engineering rigor with extensive test coverage (bytecode stability, version compatibility, round-trip, transformation passes) and careful version management for evolving the IR format. While primarily a compiler infrastructure application, the project's focus on low-precision matrix operations (FP8, FP4) and tensor core optimizations touches on ML research areas.
Shed Skin is a Python-to-C++ transpiler that translates a restricted, implicitly statically typed subset of Python 3 into optimized C++. It employs type inference to resolve types and automatically generates C++ code, which is then compiled into native executables or shared library extensions. The architecture consists of a frontend (parser, type inference, virtual analysis), a C++ code generator, and a comprehensive runtime library (implementing Python built-in types, standard library modules, and bundling Boost headers for portability). The project includes over 80 example programs covering games, simulations, compression, AI, and graphics, serving as both showcases and benchmarks. A pytest unit test suite and a CMake/ctest integration test suite validate compiler correctness. The tool is primarily a command-line application invoked via `shedskin build <script>`, producing binaries that typically achieve 1-100x speedups over CPython.
H5 is a C# to JavaScript/TypeScript transpiler that enables C# developers to target web platforms. The system consists of a compiler service (h5-compiler dotnet tool), a translator core that converts C# AST to JavaScript/TypeScript using visitor patterns and attribute-driven rules, and runtime libraries providing .NET-like functionality in JavaScript. Key features include SDK-style project integration, extensive globalization support through locale definitions, and support for JavaScript interop via attributes like [H5.External] and [H5.Template]. The toolchain processes C# source files through lexical analysis (using NRefactory), semantic analysis, translation to target language syntax, and emits JavaScript/TypeScript output with optional source maps and HTML wrappers.
Dingo is a source-to-source transpiler for a custom language that extends Go with Rust-inspired features like sum types (enums), pattern matching, error propagation (`?`), safe navigation (`?.`), null coalescing (`??`), lambdas, tuples, and functional utilities (Option/Result). The transpiled output is clean, idiomatic Go with zero runtime overhead. The repository includes a full CLI tool (`dingo`) with build, run, fmt, lint, and update commands, as well as a language server (`dingo-lsp`) that wraps gopls as a proxy and uses source maps (`.dmap` binary format) for position translation. Editor integrations cover VS Code, Neovim, and JetBrains. The codebase is organized as a monolith with a modular plugin architecture for AST transformations. While actively developed and containing several well-crafted reusable components (source map binary format, error formatting with carets and suggestions, concurrent type cache, animated terminal mascot), the project shows signs of architectural fragmentation: duplicate parser implementations, a legacy preprocessor coexisting with a newer AST pipeline, multiple skipped tests, and known incomplete features tracked in TODOs. The scope is ambitious — many language features are implemented but the overall coherence suffers from incremental AI-assisted development patterns visible in the extensive ai-docs archive.
Prog8 is a Kotlin/JVM compiler and language toolchain for retro 8-bit/16-bit platforms (C64, C128, CX16, PET32, Amiga, m68k). It compiles a high-level language to 6502/68000 assembly through a multi-stage pipeline: lexer/parser, AST construction, semantic analysis, intermediate representation, optimizer, code generation, and optional VM execution. The repository also includes an LSP server, a Gradle build with Kotest tests, CI workflows, and target-specific runtime libraries. It is primarily an application (compiler/CLI), not a data/research project.
FlexFlow Train is a deep learning framework that automatically parallelizes and distributes neural network training across GPU/CPU clusters. The system ingests models from PyTorch, Keras, ONNX, or its own C++ API, converts them into a computation graph, and then applies a multi-stage optimization pipeline: graph-level substitutions (pattern matching and rewriting), series-parallel decomposition, cost estimation, and machine mapping via MCMC or dynamic programming. The optimized parallel graph is executed on the Legion/Realm runtime, coordinating distributed tasks across devices. The codebase is organized as a C++ library with Python bindings, comprising ~3500 files including kernels, a compiler, graph utilities, and model definitions. While the core architecture demonstrates sophisticated engineering with extensive tests and reusable graph abstractions, the repository carries significant complexity from heavy template metaprogramming, two execution backends, and partially implemented CPU/HIP kernels, making it more suitable for integration by teams with C++ and distributed systems expertise.
Bob is a Scheme language implementation consisting of a Python interpreter, compiler, and virtual machine (VM), plus an optional C++ VM implementation (BareVM). The system compiles Scheme source code to custom bytecode, which can be executed by either the Python VM or the C++ BareVM. It includes features like bytecode serialization/deserialization and WebAssembly compilation. The architecture is modular with clear separation of concerns: parser, compiler, bytecode handling, VM execution, built-in functions, expression representation, and environment management. Key entry points are in bob/cmd.py (command-line interface) and example scripts demonstrating interpretation, compilation, and execution workflows.
Honey Potion is a compiler framework that translates a subset of the Elixir programming language into eBPF (extended Berkeley Packet Filter) programs, targeting both tracepoints and XDP. The system works as an Elixir library (published on Hex as `honey`) where users write eBPF logic in Elixir using macros like `@sec`, `defmap`, and `fuel`. At compile time, `__before_compile__` triggers a pipeline: static analysis, optimization (constant propagation, dead code elimination, type propagation), AST-to-C translation, boilerplate generation, and C compilation via `make`/`clang`/`llc`/`bpftool`. The generated C code includes a custom runtime with heap, tuple pool, and string pool implemented using BPF maps to overcome eBPF's stack and memory constraints. The repository includes 20+ example programs (system monitors, packet filters, data structure demos) and a comprehensive benchmark suite comparing hand-written C eBPF programs to Honey-generated ones, supporting a published research paper. Although classified as an application (a compiler library), the project has strong research characteristics with reproducible artifact scripts, optimizer variants, and performance comparisons.
BosqueCore is a compiler and toolchain for the Bosque programming language, a research-oriented language emphasizing mechanized reasoning, deterministic execution, and safe-by-design programming. The repository implements a full compilation pipeline in TypeScript: a recursive-descent parser and lexer, a semantic type checker with advanced features (invariants, pre/post conditions, validated strings, numeric range types), an IR with monomorphization, and a C++ backend that generates garbage-collected, allocation-aware code. The CLI (`src/cmd/bosque.ts`) compiles `.bsq` files to C++ and produces executables via a Makefile build system. Extensive tests cover parser, typechecker, C++ emission, and runtime execution of sample programs (raytracer, nbody, binary tree). The architecture is cleanly split between frontend (AST, parsing, checking) and backend (IR, monomorphization, C++ emission), with a hand-written recursion-descent parser and a highly detailed type system. However, the codebase is a work in progress: many language features are explicitly unimplemented (tasks, switch, dispatch, multi-return, resource/env handling) with `assert(false, "Not implemented")` stubs, and large monolithic files (e.g., `parser.ts`, `checker.ts`, `flatten.ts`) concentrate complexity. The repository also includes a C++ runtime with a custom GC and allocators, plus a lexer/serializer for the BAPI IR format. As a research project transitioning toward practical use, it offers a unique, safety-focused language design but is not yet production-ready.
Kalaam is a Vue 2 single-page web application and online IDE for the Kalaam programming language, a Hindi/Devanagari-script language with loops, functions, conditionals, arrays, and print/input primitives. The app provides documentation pages, an examples gallery, and a CodeMirror-based practice editor with standard run mode and a line-by-line learning mode. It is a static frontend with no backend; it is configured for SPA hosting via public/_redirects and embeds Google Tag Manager in the HTML entry point. Under the hood the repository ships a complete custom interpreter in src/lib: a scanner classifies source tokens, PushTokens constructs a token array, and Scripts/main.js interprets assignments, conditions, for/while loops, functions, arrays, and print statements against an in-memory variable store. The interpreter is essentially a tree-walking evaluator that relies heavily on JavaScript eval(), uses browser prompt() for user input, and generates Hindi execution-stack explanations for educational output. Notably, the live Practice.vue imports Compile and KalaamKeywords from the external 'kalaam' npm package, while the Jest tests exercise the local src/lib/Compiler/main.js instead, creating a split between the tested compiler and the compiler actually used by the app. The codebase is functional for the bundled examples but shows significant engineering debt: duplicate compiler trees under src/lib/Interpretor(temp), global Array.prototype mutation, dead code, legacy Vue 2/Quasar 1 dependencies, and heavy coupling between interpreter modules. The main reusable value is in the language-tooling pieces, such as the CodeMirror mode, token scanner, and source-normalization utilities. Overall this is best viewed as an educational/experimental language project rather than a cleanly architected production codebase.
Vue Native Core is a deprecated fork of Vue.js 2.x that compiles Vue component templates into render functions compatible with React Native (iOS/Android) and React Web. It provides a full reactive state management system (Vue's observer pattern), virtual DOM diffing, and a template compiler pipeline that transforms .vue single-file components into JavaScript modules usable by React Native's Metro bundler. The architecture mirrors Vue 2: core reactivity (Dep, Watcher, Scheduler), virtual DOM (createElement, patch), and a multi-stage compiler (parser → AST → code generator) with platform-specific backends for native and web. It also offers runtime helpers to emulate Vue directives (v-if, v-for, events) and component lifecycle in React. However, the project is explicitly deprecated, depends on outdated versions (Babel 6, React 16.8, React Native 0.45–0.59+), and uses deprecated React lifecycle methods (UNSAFE_componentWillMount). The codebase shows heavy modification of core Vue files, making it difficult to merge upstream updates, and its build system is complex and fragile. Despite these issues, the reactive state wrapper (Vue.observer) and the template-to-render compilers demonstrate non-trivial adaptation of Vue to React ecosystem.