The EDG compiler: a C and C++ front end built to be embedded in other products

The front end is the product, not the code generator

The repository's own framing is unusually direct. It calls the EDG C/C++ front end the primary focus of the project, and gives three reasons for its reputation: parsing compatibility and bug emulation, extensive documentation, and extreme configurability so the front end can be derived for use in many C and C++ oriented products.

That last reason is the one that decides who should care. EDG is not positioned as a compiler you invoke to turn .cpp files into objects. It is positioned as an engine you embed. A team that wants to build a source-to-source transformation tool, a checker, or a product that must parse C++ the way a major vendor does has exactly this problem, and building a C++ parser from scratch is famously worse than reusing one.

The compatibility claim is stated in a specific and testable way: source that compiles with Clang, GCC and MSVC is meant to compile with EDG, with the front end emulating the bugs of those compilers. Bug emulation is a deliberate feature rather than a side effect. It exists because a code analysis tool that flags an error a compiler accepts is a tool people switch off.

The topic tags on the repository are compilers, cpp, cpp-programming, and one tag per standard from cpp98 through cpp23, which is a reasonable summary of the range the front end is expected to cover.

Two back ends, a prelinker and a deliberately thin runtime

Around the front end, the project ships a specific set of components, and the README is candid about what is not in them.

There is a C-generating back end, whose stated purpose is to generate C code for C++ programs. And there is a C++-generating back end, described as useful for source-to-source transformation applications. Two back ends to the same front end is the shape of a toolchain product: the C++ output feeds a transformation, the C output feeds a different downstream path.

Then there is a prelinker, which handles automatic template instantiation. This is the piece that most distinguishes EDG from a plain parser. Templates in C++ are instantiated at the point of use, and something has to decide where those instantiations are emitted. Doing that in a prelinker rather than during the initial compile changes the build model, and it is the kind of component that has no drop-in replacement in a smaller tool.

The runtime support library is described as minimal, and the README is explicit that there are no real libraries, giving stream I/O as the example of what is absent. So a consumer of this project needs to bring its own standard library, which is fine for an analysis tool that never executes the code and is a serious obstacle for anyone hoping to build a complete system this way.

The remaining pieces are developer utilities: tools to write the intermediate language to a file, read it back in, and display it in human-readable form, a name demangler, and a collection of purpose built development tools. The intermediate language round trip is quietly important, because it is what makes the front end inspectable from outside.

Getting the source: a blobless clone over SSH

The README gives a specific recommendation for how to check the project out, and the reasoning is worth repeating because it affects how long the first clone takes.

git clone --filter=blob:none [email protected]:edgcpp/compiler.git

A partial clone with blob filtering keeps the full copy of the git history while downloading only the most recent version of each file, with git able to fetch older versions on demand. For a repository of this size, that difference decides whether the first clone is a coffee break or a long evening.

The URL is an SSH form, so a fresh clone needs a GitHub key configured, and the working directory will be a git repository on the main branch.

From there the README splits the audience. If you want to build the front end from source and use it, the pointer is to BUILD.md. If you want to make changes, the pointers are to the contribution guide at CONTRIBUTING.md and the development guide at HACKING.md, which is described as being for quickly getting set up. Two different starting points, and the choice matters if you are trying to decide whether the project is consumable as a library or only as a working compiler.

The repository root supports the build rather than merely holding sources. There is a CMakeLists.txt and a CMakePresets.json, so a CMake configure is the likely path. There is also a dev-init.py script, an .envrc file, a .git-hooks/ directory, and a .pre-commit-style .github/ directory, which together suggest the project expects a scripted environment setup before a build. An AGENTS.md file and a .agents/ directory indicate the project has been set up for work by automated coding agents as well as by people.

Two documentation sets, one for the current branch and one for main

Documentation is one of the three things the README claims for the front end, and the structure backs that up.

There is a general documentation site at https://edgcpp.org/doc/ and a separate set for the current development branch at https://edgcpp.org/dev/doc/. The split matters more than it looks. The default branch of the repository is main, and the development-branch documentation is the one that describes the code you are actually looking at. A reader who reads only the stable documentation while reading main source will hit mismatches.

The doc/ directory in the repository holds the sources for that documentation, and doc/README.md is described as a documentation build guide for people who want to build a local copy. The dev_annex/ directory is separate again, and the README describes it as additional documentation for tips, tricks and tutorials, written to aid humans and AI agents in product development. That framing is unusual. It suggests the maintainers expect this repository to be forked and modified by product teams, and have written down the hard-won knowledge separately from the reference manual for exactly that reason.

The wider documentation surface is extensive: BUILD.md for building, CONTRIBUTING.md for contributing, HACKING.md for internal development, and the annex on top. What is not visible in the README is any statement about what is guaranteed stable across versions, or how the documentation maps to a released configuration, and there are no GitHub releases to anchor a version against.

Bug emulation is the feature, and also the risk

The most interesting design decision in this project is the one that would look like a defect in a conventional compiler: the front end emulates the bugs of Clang, GCC and MSVC.

The benefit is compatibility. A tool built on EDG accepts the same programs the major compilers accept, including programs that depend on sloppy behaviour, which is what makes the tool usable on real codebases. The benefit for a product team is sharper still: if your analysis has to agree with a compiler that your users already run, matching that compiler is the requirement, and bug-for-bug fidelity is how you get there.

The cost is that a whole category of behaviour you might want to reject is deliberately accepted. Compiler bugs that are emulated are bugs your downstream tool inherits, and a divergence between EDG and the actual compiler your customer runs is exactly the failure mode this design is meant to prevent but cannot fully. The README's framing is compatibility with Clang, GCC and MSVC collectively, which raises a second question the documentation does not answer here: which vendor behaviour is being emulated when they differ, and whether that choice is configurable. The stated emphasis on extreme configurability suggests it is, but the README does not name the switch.

For a reader deciding whether to adopt, the honest test is the compatibility claim itself. Take a corpus of your own code, compile it with the compiler you care about, and see whether EDG accepts the same set. That is a measurement you can make, and the repository provides the test infrastructure under tests/ and benchmarks/ to do it in.

The licence field classifies nothing, so read LICENSE.txt

The licence field on the repository says Other, which the platform notes it cannot classify, and points to the licence file. The file at the root is LICENSE.txt.

This is a case where metadata and file can be read either way, so treat the file as the source of truth and check it before you plan to ship anything built on this code. Since the front end is designed to be derived and embedded in commercial products, the terms of the licence file determine whether that plan is open to you. Nothing in the README summarises the terms, and this is not legal advice, so the read is on you.

Two adjacent notes. The repository also contains a NOTICE-style file named LICENSE.txt alongside include_c99/ and include_c++/ directories and a lib_src/ directory, which suggests bundled header and library material that may carry its own separate terms. And the CHANGELOG route that other projects rely on is not available here, because there are no GitHub releases to diff.

On maintenance, the facts are narrow but current. The repository is not archived, and the last push was on 2026-10-19. There are no GitHub releases, so there is no version number to pin when you vendor this, and you should record a commit hash instead of a tag.

Where this repository is the wrong choice

It is worth being blunt about the cases where adopting EDG is a mistake.

If you want a C++ compiler to build your project, this is the wrong repository. There is no gcc or clang replacement here, no driver with the familiar command line, and no complete runtime. The README says the runtime support library is minimal and that real libraries, including stream I/O, are absent, so the code produced by the back ends needs a standard library from somewhere else.

If you are not prepared to build a compiler, this is also wrong. A CMake configure, a prelinker step, intermediate language tooling and an environment setup script describe a toolchain with real build-time cost. Anyone who just wants to parse C++ for a small validation task will spend more time on the build than on the problem.

And if you need stability guarantees, the signals are weak. No releases, no tags, an unclassified licence field, and a documentation split between a stable site and a development-branch site. The README's own claim of a development branch for main tells you that main moves.

The genuine alternative for most readers is a mainstream compiler, and the difference in approach is exactly the point of this project: those tools give you a finished program, while EDG gives you a configurable front end you can derive. For a source-to-source transformation product, that is a capability those tools do not expose, and the derivation cost is the price of getting it.

Editorial conclusion

Adopt this repository if you are building a source-to-source tool, a code analyser, or a product that needs a C++ front end you can configure, and you have the patience for a codebase driven by a CMake build with its own prelinker and intermediate language. Do not adopt it looking for a drop-in gcc replacement or for a production C++ standard library, because the runtime shipped here is explicitly minimal and the repository publishes no releases. Before anything else, read BUILD.md, then skim HACKING.md and the dev_annex/README.md annex, and check LICENSE.txt directly, since the licence field on the repository says Other and classifies nothing on its own.

Frequently asked questions

Official sources

1. edgcpp/compiler on GitHub
2. Issues
3. Project website
4. README