# slang, a SystemVerilog frontend that is meant to be embedded rather than run

> slang is a C++ library for lexing, parsing, type checking and elaborating SystemVerilog, shipped with a command line tool that compiles and analyses projects on its own. Its design bets on two things: a parse tree that round trips back to the source, and a compiler that stays useful on broken code, which is what makes it viable as an editor language server.

**MikePopoloski/slang** — SystemVerilog compiler and language services

- Repository: https://github.com/MikePopoloski/slang
- Stars: 1,172 · Forks: 276
- Language: C++
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/mikepopoloski-slang

## A library first, a tool second

The description is precise about the layering. slang is a software library that provides various components for lexing, parsing, type checking and elaborating SystemVerilog code, and it comes with an executable tool that can compile and statically analyze any SystemVerilog project, but it is also intended to be usable as a front end for synthesis tools, simulators, linters, code editors and refactoring tools. The order of those words matters. A tool that is a library first can be adopted by a synthesis vendor or a linter author without asking anyone to switch their command line, and the executable is then a thin driver over the same code. The documentation is split accordingly, with a user manual for people running the binary and a separate developer guide for people linking the library. The project also points at a web playground for trying parsing, type checking and error detection live, inspired by the Compiler Explorer.

```bash
git clone https://github.com/MikePopoloski/slang.git
cd slang
cmake -B build
cmake --build build -j
```

## The round-tripping parse tree is the load-bearing idea

Two features do most of the work for downstream tool authors, and they are stated more concretely than a feature list usually is. The first is that the parse tree should round trip back to the original source, which makes it easy to write refactoring and code generation tools. A parse tree that loses formatting, comments and whitespace is fine for a compiler, which only needs semantics, and useless for a refactoring tool, which has to write the file back. A tree that round trips is a document model, and it is what turns slang from a front end into a platform for tools that edit code. The second is robustness about compilation no matter how broken the source text, and the reason given is specific: this makes the compiler usable in editor highlighting and completion scenarios, where the code is likely to be broken because the user is still writing it. Most compilers assume a valid program and fall over on an incomplete one, which is exactly the wrong behaviour for a language server that re-parses on every keystroke.

```
- The parse tree should round trip back to the original source,
  making it easy to write refactoring and code generation tools.
```

## The seven use cases the project names

The use case list is a good map of what the library is actually good at, and each entry corresponds to a different way of consuming the same core. As a very fast syntax checking and linting tool, which is the entry point for most people. Dumping the AST of your project to JSON, which is how you get a machine-readable view of a design without writing a parser. Source code introspection via the included Python bindings, which is how a script drives the frontend without linking C++. SystemVerilog code generation and refactoring, which is the use the round-tripping tree enables. As the engine for an editor language server, which is the case that the robustness requirement serves. As a fast and robust preprocessor that sits in front of downstream tools, so you preprocess once rather than letting every tool do its own include resolution. And as a front end for a synthesis or simulation tool by including slang as a library, which is the case for tool vendors. The claimed performance position is stated too: the fastest and most compliant SystemVerilog frontend, according to the open source chipsalliance test suite.

```
- Very fast syntax checking and linting tool
- Dumping the AST of your project to JSON
- Source code introspection via included Python bindings
- SystemVerilog code generation and refactoring
- As the engine for an editor language server
- As a frontend for a synthesis or simulation tool
```

## Building, binaries and the Python bindings

The build is CMake, and the short version of the instructions is a configure into a build directory followed by a parallel build. Pre-built binaries for Linux, macOS and Windows are available on the releases page, which is the sensible starting point for anyone who wants to try the tool before committing to a build. The project can be run on your code right out of the box once built, with the user manual explaining how it works. The Python bindings are a separate distribution named pyslang, installable from PyPI with a single pip command, and the pyslang directory in the repository holds tests and examples showing how to use the Python API. The packaging metadata for that distribution is informative about how it is built: it uses nanobind for the binding layer, with scikit-build-core as the build backend and the CMake source directory pointing at the repository root, so the Python package compiles the C++ library as part of its own build rather than shipping a binary wheel of a prebuilt library. The package requires Python 3.11 or newer.

```bash
pip install pyslang
```

## Diagnostics, and what clang-like means

The feature list claims great error messages, ala clang, and it is worth taking that claim seriously as a design commitment rather than a nicety. For a language that is a superset of Verilog with a large collection of corner cases, the difference between a diagnostic that says the expression is not assignable and one that points at the operator that makes it not assignable is the difference between a tool a hardware engineer uses and a tool they work around. That claim also connects to the round-tripping tree, because a diagnostic that names a source range can be attached to the actual text, which is only useful if the tree keeps the text. The project reports coverage through codecov, so the error paths are exercised by the test suite rather than being an afterthought, and the CI badge in the README is for the CI build workflow. Support is handled through GitHub issues and discussion threads, and the contribution guidance is explicit that bug reports, comments, suggestions, documentation improvements and new features are all welcome through pull requests.

```
- Provide great error messages, ala clang.
```

## The repository shape, and the REUSE licensing setup

The tree is that of a serious C++ project. There is an include/ directory for the public headers, a source/ directory for the implementation, tests/, tools/ and scripts/, plus a bindings/ directory that sits alongside the pyslang/ Python package, an examples/ directory with an integration example, and external/ for vendored third-party code. The build definition is a CMakeLists.txt with a CMakePresets.json beside it, and there is a cmake/ directory for the project's own CMake modules, so the build is designed to be consumed by other projects rather than only run in place. Two files are unusual and worth naming. There is a .clang-format and a .clang-tidy, so both formatting and linting are enforced by configuration rather than by review. And there is a REUSE.toml alongside a LICENSES/ directory, which is the REUSE specification for software licensing, a way of recording per-file copyright and licence metadata in a machine-readable way for a project with many files and mixed sources. The top level also carries a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a CHANGELOG.md.

```
include/
source/
tests/
tools/
bindings/
pyslang/
examples/
external/
LICENSES/
REUSE.toml
```

## Version cadence and where it fits

The release history shows a project on a steady major-version cadence: v12.0 on 2026-09-29, v11.0 on 2026-05-15 and v10.0 on 2026-01-15, so roughly every four months, with the last push to the repository on 2026-10-18 and the repository not archived. The Python package tracks the same numbers, with the pyproject version at 12.0.0 matching the v12.0 release, which is the right relationship between a binding and its core. The licence is MIT, with the copyright holder named as Michael Popoloski and the standard grant reproduced in full in the README, and the licence identifier in the repository metadata is MIT as well, so there is no ambiguity there. The practical fit is narrow but real. If you are writing hardware, slang is not how you simulate, and it is not a replacement for a vendor toolchain. It is the thing you reach for when you need to analyse SystemVerilog faster than a simulator can, when you want to build a tool on top of the language rather than a tool for it, or when you want an editor to understand the code your team is writing.

## Conclusion

Adopt slang if your SystemVerilog toolchain needs a fast, compliant front end, whether you are writing a linter, an editor integration, a code generator or a synthesis front end, and skip it if you only want to compile a design, because a simulator or synthesis tool already includes one. Verify three things before you commit: that your SystemVerilog feature set is covered, since the claim is that all features are parsed, elaborated and analysed, and your corner of the language may still be where the standard is less settled; that you can live with the error message style, since the project describes its diagnostics as clang-like and that is a strong claim to test against your own expectations; and that the version you pin is one whose changelog you have read, since major versions land roughly every four months and the API is a C++ library interface rather than a stable CLI.

## FAQ

### What is slang?

It is a C++ software library providing components for lexing, parsing, type checking and elaborating SystemVerilog code, shipped with an executable tool that can compile and statically analyze any SystemVerilog project, and intended to be usable as a front end for synthesis tools, simulators, linters, code editors and refactoring tools.

### Why does slang matter for editor and language server use?

Because it is robust about compilation no matter how broken the source text, which the documentation says makes it usable in editor highlighting and completion scenarios where the code is likely to be broken because the user is still writing it. Its parse tree also round trips back to the original source.

### How do I build slang from source?

Clone the repository, run `cmake -B build` and then `cmake --build build -j`. Pre-built binaries for Linux, macOS and Windows are also available on the releases page, and the user manual explains how to run the binary once built.

### How do I use slang from Python?

Install the pyslang bindings from PyPI with `pip install pyslang`. The project describes them as Python bindings for the library, and the pyslang directory in the repository contains tests and examples showing how to use the Python API.

## Sources

- [Issues](https://github.com/MikePopoloski/slang/issues)
- [License: MIT](https://github.com/MikePopoloski/slang/blob/master/LICENSE)
- [MikePopoloski/slang on GitHub](https://github.com/MikePopoloski/slang)
- [README](https://github.com/MikePopoloski/slang/blob/master/README.md)
- [Releases](https://github.com/MikePopoloski/slang/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mikepopoloski-slang