For a fun experiment I used Opus 5.5 to fork ccls, clang-based C++ language server, into “edgls” (https://github.com/MaskRay/edgls/) and replaced every use of the clang API with this front end. Definition and references, hover, call and inheritance hierarchies, rename, and diagnostics all work on real projects.

It’s much slower than clang though: Indexing ccls itself (41 TUs, 8 threads): 9.5 (edgls) s vs 6.3 (ccls) s, with 6.1 GB vs 2.5 GB peak memory. Parse-only, EDG is about 1.7× slower than clang -fsyntax-only on that code.

score 1 · canonical

The Orange C++ compiler for Windows is still actively maintained to this day https://github.com/LADSoft/OrangeC

For years they claimed C++14 but recently started supporting C++17

score 1 · canonical

This is really cool to see. Back when C++ compatibility in compilers was generally terrible in the late 1990s and early 2000s, you’d always hear stories about the compatibility level of EDG’s frontend. I didn’t get to use an EDG-based compiler until working with the Green Hills toolchains for some of Nintendo’s consoles.

At least as far as my knowledge extends this is one of the four still extant C++ front ends (Clang, GCC, and MSVC being the others).

One thing that surprised me when I asked him about it years ago is that Sean Baxter’s Circle is an independent C++ front-end implementation, in addition to the Circle-specific features. I’d previously assumed that he’d started with the Clang front-end.

score 2 · canonical